Add repl tab complete hints while typing

[IanButterworth]

Tab complete hints show automatically as you type, then use tab to complete.

(I'm typing slower here to illustrate it. It's very responsive for me and appears adequately baked into the sysimage)

Screen.Recording.2023-09-08.at.10.01.22.AM.mov

TODO

• Figure out why the 2 repl history keymap tests are failing
• add way to disable hints
• make sure it's compatible with OhMyREPL Show tab complete hints, if supported KristofferC/OhMyREPL.jl#330

[mkitti]

Very nice. I had to watch the video to understand what you mean.

Maybe the title of "Add an inline preview of tab complete hints to the REPL" would more clearly identify what this does.

[rfourquet]

This looks great! We probably need though a way to opt-out via something like Base.active_repl.options.hints = false.

[IanButterworth]

Agreed. I also think that after the public api mechanism merges hints should maybe only show up for public names, even if tab completes for all. But that's more opinionated and for later.

Or maybe private names show up in a different color and after a delay..

[vtjnash]

I am experiencing frequent REPL corruption now where I lose part of the line or it prints wrong. For example, if you type

julia> using Cthu, REPL

then mouse back and change that to

julia> using Cthulhu, REPL

when you start typing, it will garble the rest of the line. Then when you type the final u, the line gets fully deleted. Once you type another character, then it gets restored correctly.

[IanButterworth]

I have a fix ready. Basically it limits to only doing hints for the end of the line. Inserting hints at earlier positions would take a lot of work in the printing logic I think so best to just limit it for now.

Maybe it's possible to implement earlier hints before 1.11 is out.

Also I'm considering not hinting on single characters, given x shows xor as a hint which is a bit awkward.

[vtjnash]

That seems useful. Could you also make the hint print with light colors?

[IanButterworth]

It already prints in :light_black which seems like the right choice?

[vtjnash]

Oh, I see, I am using TERM=screen-256color and I don't have the terminal file for that (only for screen-256color-s with an added status line feature), so Julia is not printing any colors for me

[timholy]

I've not used Julia 1.11 a lot yet, but I just disabled this feature. Might be worth canvasing folks before release to figure out whether this should be enabled by default.

Maybe the NEWS should also list more complete options for people who use multiple Julia versions, e.g., "Put this in your .julia/config/startup.jl:

using REPL
if isdefined(Base, :active_repl_options) && Base.active_repl != nothing && hasfield(REPL.Options, :hint_tab_completes)
    Base.active_repl.options.hint_tab_completes = false
end

[IanButterworth]

Oof that does require a lot of conditionals to turn off in previous versions.. maybe we should add an env var..

If you don't mind, could you elaborate why you want to disable this?

I've not heard of anyone doing so (and the convoluted way you have to do so in startup.jl makes me wonder if anyone else actually has), so the feedback would be helpful.

[timholy]

Not 100% sure I know why I don't like it, but it feels "laggy." I'm not sure whether it lags the keyboard, or whether the sudden appearance of visual stimuli lags my brain. Subjectively it makes the REPL experience feel like it stutters. I tend to like the tab completions in VSCode and elsewhere, so I don't think it's just me being anti-completion.

As for why I might be different, I haven't looked at how this is implemented and thus how deep the search goes, but one thing to know is that I have two registries, General and HolyLab. Any chance that's more than a red herring?

[IanButterworth]

I have those registries plus another and it's lag free for me.

Linux? Master commit?

[timholy]

julia> versioninfo()
Julia Version 1.11.0-DEV.1351
Commit 47d31acd14* (2024-01-22 09:46 UTC)
Platform Info:
  OS: Linux (x86_64-linux-gnu)
  CPU: 16 × 12th Gen Intel(R) Core(TM) i7-1260P
  WORD_SIZE: 64
  LLVM: libLLVM-16.0.6 (ORCJIT, alderlake)
Threads: 1 default, 0 interactive, 1 GC (on 16 virtual cores)
Environment:
  JULIA_IMAGE_THREADS = 4

It's actually WSL. Windows seems slow at file operations, maybe that's part of it?

[timholy]

Oh, also funny: since I am working on SnoopCompile I was using --startup=no (to minimize invalidations) so I hadn't actually tested it. It turns out that startup.jl runs before isdefined(Base, :active_repl) returns true. So that startup.jl setting won't work anyway. Maybe Preferences?

[IanButterworth]

Ah yes. The shell> tab complete PATH scan on WSL is pathologically slow.. On Cody's machine takes 20s whereas on my Mac it takes 0.01s. As a result we made it asynchronous and cached. There may still be room for improvement.

If you get a chance to try julia on a native system, could you see if it's still something you'd want to disable?

Also a screen recording would help understand. I've tried to set up WSL for testing but I only have access to a Windows VM, and WSL in a windows vm on an apple silicon Mac doesn't even load julia for me

[mkitti]

Windows stat operations are around 100x slower than Linux or WSL. That's the legacy of Win32.

[IanButterworth]

For disabling this in startup.jl perhaps this is the simplest for now (until we set up a Preferences approach)

if VERSION >= v"1.11.0-0"
    atreplinit() do repl
        repl.options.hint_tab_completes = false
    end
end

[IanButterworth]

@mkitti WSL compounds the issue by appending the full Windows PATH to the linux PATH.

So fs operations are much slower, and the scan is a lot bigger. (PATH has ~1500 reachable files on my Mac, ~7000 on Cody's WSL)

More details in #52833 #52893