Thanks for this idea. I like it and I think this should be simple to implement. However, we might even have the extended help on <F1> if there are no reasons against it.
In Terminal.app changed settings as suggested, now <alt> + <h> works.
Just: On my German keyboard I need the <alt> modifier to type such important characters as @ [ { ] }, now it was impossible 
Also, actually I use VSCode, like probably the majority of Julia users.
Good that we found that it is no inherent technical problem of TerminalPager.jl, although I understand that the cure is probably worse than the disease for you.
Maybe other Mac users can jump in. On a German keyboard you would typically press <Alt Gr> to access the characters you listed. I donât know whether this is the same on a Mac.
Alternatively, maybe you can selectively bind some key combinations? Claude again:
Solution 1: Selective Meta Key Configuration
Instead of enabling âUse Option as Meta keyâ globally, you can:
Go to Terminal.app â Preferences â Profiles â Keyboard
Look for individual key mappings
Configure only specific Option+key combinations as Meta keys
Leave the ones you need for special characters (like Option+L for @, Option+8 for [, etc.) unconfigured
Solution 2: Create Custom Key Mappings
In Terminal.app Preferences â Profiles â Keyboard:
Click the â+â button to add new key mappings
For each special character, create a mapping:
Key: Option + the key you want to use
Action: âSend Textâ
Text: The actual character (e.g., @, [, {, etc.)
On Mac, the left and right <alt> are equivalent.
I can try selective mappings, but probably not today.
Do you have any ideas for VSCode users?
Having effectively no <alt gr> key seems to be a serious limitation for a German user, which is probably unacceptable for most German Mac power users. So there are probably solutions for this problem and I hope that other Mac users jump in to help.
What I would try:
- VSCode allows using an external terminal (the first option in
settingsâFeaturesâTerminal. I donât know whether that helps with key bindings, but itâs probably worth a try. - Claude pointed towards Karabiner-Elements which seems to be able to do fancy keyboard stuff on a Mac
I consider myself a power Mac user (at least, I used quite a lot of different programs on Mac over the last 30 years). This was the first time I got issues because of not having <alt gr>.
Concerning using an external terminal with VSCode: The built-in one is tighty integrated, which Iâd probably lose with external one. Or how is it? Anyway, for me personally it is likely not worth the trouble.
Sorry, my post was misleading. I meant Mac power users on the terminal, as there <alt> is important for a lot of readline shortcuts, see e.g for the Fish shell. On the other hand, missing <alt gr> as a German user would also be a serious drawback. Thatâs why I really think there are solutions to this problem (as they are different keys, they send different key codes, so an application probably can distinguish them if needed).
The external terminal is still included in VSCode. You do not necessarily see a huge difference, itâs just a different terminal emulator. I use my preferred terminal emulator as an âexternalâ terminal. I never missed the VSCode one.
I agree, that this sounds like too much trouble for something which should be simple. But we can define whatever shortcut we want. So what would be a good default key combination for a Mac user to access help?
In the long run, we should make the shortcut user-configurable anyway. @Ronis_BR already put the infrastructure into place in TerminalPager.jl for pager shortcuts, so I hope we can build on this for the help shortcut.
Many terminals on macOS allow you to remap one option key as alt (most commonly the left one I think) and keep the other one as option, which sounds like a fairly decent compromise. Looks like the built-in Terminal.app doesnât have this, but popular ones like iTerm2 and Ghostty do. No idea about the VSCode one.
I guess the reason would be that you might want to provide access to both the regular and extended help without using the alt shortcuts (not to go full xkcd 1172, but I currently use alt(+shift)+{h,j,k,l} for window navigation/management, which is why Iâm currently not able to use alt(+shift)+h in the REPL).
Yes, understood, with this proposal both <F1> and <alt> + <h> (and maybe more to cover Mac users) would be extended help. We could not identify any relevant benefits in the linked issue above to provide the regular help when using a pager.
1 Like
You can also press escape and then h in the REPL (the way it used to be in the beginning).
I rather keep the option modifier for Unicode input and use the escape key for, well, escape sequences.
2 Likes
Yes that works, and thatâs all I need!
1 Like
My behavior is similar to Jakeâs but I am on v0.6.6. I am on Windows 11, getting the same behavior in Powershell and VSCode with a U.S. keyboard. Any ideas?
I enter the pager mode with | and type startswith(, then
<alt> + <b>and<alt> + <f>move the cursor back and forward as expected<alt> + <h>does nothingF1inserts anA<esc>,<h>does nothing
Environment Details
(@v1.12) pkg> st
Status `C:\Users\nboyer.AIP\.julia\environments\v1.12\Project.toml`
[09cdc199] BasicAutoloads v1.0.4
[5903a43b] Infiltrator v1.9.3
[5fb14364] OhMyREPL v0.5.32
[295af30f] Revise v3.11.0
[27c01619] ShareAdd v2.4.0
[0c614874] TerminalPager v0.6.6
This is a good point. The help mode is currently only implemented in the normal REPL mode, not in the pager mode.
Can you please test it again in the regular REPL mode?
However, I like your (involuntary?) feature request and created a PR to also make it available in pager mode.
1 Like
Missed that detail. Works now!
1 Like
When I press <alt> + <h> on an incomplete function call like
julia> f(x,
I seem get all docstrings for f. This includes docstrings for f() and those where the type of x doesnât match. Is this intended?
This is why I love working with the Julia community! You think you have a good feature and after a lot of clever ideas and questions from the community (as we have already seen so many in this thread), you realize that you could actually have a great feature when you implement all the ideas coming out of this exchange.
To answer your question: Yes, it is intended in the sense that as far as I know no one has thought about it, yet. Actually, I didnât even remember, that in REPLâs help mode, you can write the method instead of the function and then the output only contains help for the specific method and not all methods of the function:
julia> a = 'c'
'c': ASCII/Unicode U+0063 (category Ll: Letter, lowercase)
julia> b = "abc"
"abc"
help?> findfirst(a, b)
findfirst(ch::AbstractChar, string::AbstractString)
[âŚ]
It would be really great if this could be extended to partial argument lists of callables, so thanks for the suggestion, @matthias314! I created a PR to track it.
As much as Iâd like to have this feature, this might be some work to implement. Currently, the inline help partially reuses REPLâs help functionality if I got this right, which only supports complete function calls according to my short tests. So ideally, this feature would be implemented in the REPL itself to avoid code duplication and as it would be valuable there, too.
Maybe the REPL already supports it and I just donât know how to use it there, or the solution of the VSCode plugin can be reused or there is a different package with such functionality.
Does anyone know whether such a logic already exists in the Julia ecosystem?
2 Likes
For what itâs worth - on my german keyboard macbook I have set the right option key to input unicode characters since for all the characters I type in the terminal (@{}|) I do so using the right opt key.
This allows me to send escape sequences via the left opt key (by setting âuse left opt as metaâ or equivalent in the settings of the terminal emulator).
1 Like
TAB completion in the REPL has this:
julia> f(x) = 1; f(x::Int, y) = 2; f(x, y, z) = 3;
julia> f('a', # press <tab>
f(x, y, z) @ Main REPL[1]:1
f(x) @ Main REPL[1]:1
This is interesting. Especially, as it could be improved, as only the third method seems plausible after the comma has been entered.
I think we could filter the method table with the information we already have from the incomplete argument tuple. However, in general we will have ambiguities here, even if the complete argument tuple, aka multiple dispatch, does not have ambiguities. Therefore, we would need to filter the help to a subset of the possible entries. We know how to show the docstring of all methods and we know how to show the docstring of a specific method, but how to display the help of a non-singleton true subset of all methods?