REPL: Show input alias (e.g., \\:cat:) for Char display

[ShahabSL]

This PR enhances the REPL display for Char types.

It adds the LaTeX/emoji input alias after the standard Unicode information, making it consistent with the help?> mode behavior.

For example, '😼' will now display as:
'😼': Unicode U+1F63C (category So: Symbol, other), input as \:smirk_cat:

(Self-contained paragraph explaining the choice):
Considered modifying Base.show directly, but opted for adding a REPL.show_repl method instead to avoid introducing a dependency from Base on the REPL module's symbol mapping (symbol_latex). This approach keeps the REPL-specific display logic contained within the REPL module.

Closes #58158

[mcabbott]

Seems like a good idea. But if I load it by @eval REPL function show_repl(io::IO, ..., it doesn't seem to be called -- should that work? (Edit, on 1.11. Works on master.)

I wanted to check whether collect("αβγ") would also take this path. (It does not, which is a pity?)

[ShahabSL]

Thanks for the feedback! I tested the @eval approach on my build to understand the behavior.

After running using REPL first, I was able to successfully define a modified show_repl method using @eval REPL function.... When I then displayed a character like 'α', the output confirmed that the dynamically defined method was called (it printed a debug message I added and changed the output format as expected):

julia> using REPL

julia> @eval REPL function show_repl(io::IO, mime::MIME"text/plain", c::AbstractChar)
           println(stderr, ">>> Debug: Entering the @eval'd show_repl method!") # Added for testing
           show(io, mime, c)
           latex = REPL.symbol_latex(string(c))
           if !isempty(latex)
               print(io, ", === Alias from @eval'd method: ") # Changed text/color
               printstyled(io, latex, color=:yellow)
           end
       end
show_repl (generic function with 4 methods)

julia> 'α'
>>> Debug: Entering the @eval'd show_repl method!
'α': Unicode U+03B1 (category Ll: Letter, lowercase), === Alias from @eval'd method: \alpha

So it seems dynamic definition does work for this call path at runtime, although I understand rebuilding is the standard way to test source changes incorporated during the build process.

Regarding collect("αβγ"), you are correct that it produces a Vector{Char} and wouldn't hit this AbstractChar-specific method due to dispatch.

[ararslan]

Welcome, and thanks for the contribution! This seems like a good addition to me. It would be great if you could add tests for this method that exercise the different possible code paths.

[ShahabSL]

Thanks so much for the welcome and the helpful feedback, @ararslan! I really appreciate you taking the time to review.

I've pushed commits addressing the suggestions:

• Added <tab> to the alias output to match help mode, as suggested.
• Removed the # new method comment.
• Added tests in stdlib/REPL/test/repl.jl covering the different code paths (characters with and without aliases, handling color output).

The local tests for stdlib/REPL/test/repl.jl are passing on my end. Hopefully, this looks good now. Ready for another look when you get a chance!

[ararslan]

The implementation looks great to me, nice work! It occurred to me that since this is a new feature, a NEW.md entry could also be worthwhile, for example:

--- a/NEWS.md
+++ b/NEWS.md
@@ -49,6 +49,8 @@ Standard library changes

 #### REPL

+* The display of `AbstractChar`s in the main REPL mode now includes LaTeX input information like what is shown in help mode ([#58181]).
+
 #### Test

 * Test failures when using the `@test` macro now show evaluated arguments for all function calls ([#57825], [#57839]).

[ShahabSL]

Thanks so much for all the guidance, @ararslan! I've added the NEWS.md entry as requested and pushed the change.

As this was my first issue, I really appreciate you taking the time for the detailed reviews and helpful suggestions throughout this process. It's been a great learning experience!

Ready for another look when you get a chance.

[LilithHafner]

Thanks for contributing, @ShahabSL! This is a nice usability feature that some folks might come to depend on in some edge cases. Sorry it took so long to get back to you this time with another round of feedback. Everything looked good to me so I went ahead and merged it :)

[ShahabSL]

Hi @LilithHafner, that's fantastic to hear! Thank you so much for merging this and for your kind words. I'm really glad you see it as a nice usability feature. Absolutely no worries at all about any delay, I truly appreciate you taking the time for the final review and getting it merged. It's wonderful to see it in! I'm especially thrilled as this was my first feature contribution, and it's been such a positive learning experience. 😊

[ararslan]

Yes, apologies for the delayed response, I've been slammed with work lately and haven't had time to keep up with open source notifications. Thanks for merging, @LilithHafner, and thanks again for the contribution, @ShahabSL!