The Fanciest REPL History in the Land

[tecosaur]

The Fanciest REPL History in the Land ✨

Do you dread typing out code for the second time? Are you a particular enjoyed of REPL history?

Well, I know I am, and for years I have yearned for something better than the current readline-style completion, better than OhMyREPL.jl's fzf-driven completion, better than any REPL history I've seen before!

It's not quite finished baking, but we're onto the final stretch 😀

repl_history_demo.webm

Thanks to @kdheepak, @jakobnissen, and @digital-carver for helping me design the UI and UX over on Zulip (#repl > Revamped REPL history).

Features

• Zippy searching
  • Event-driven asynchronous filtering UI
  • Incremental, resumable searching with dynamic batch sizes
  • Log-structured search checkpoints
• Multi-selection
• Faster histfile parsing (~2x)
• Multiple search modes
• A friendly help page
• Syntax highlighting
• Save multiple items to a file or your clipboard

TODO

• Introduce annotation-preserving replace method
• Thoroughly test the new replace method
• Ask somebody more compiler-y about the performance pitfalls of the replace method (see: the REVIEW: ... code comments in annotated_io.jl)
• Implement flashy REPL history
• Restore up/down arrow history rotation in the REPL (collateral damage of over-zealous deleting)
• Create a new test set for the new history
• Make sure that enough is precompiled to be relatively snappy

---

This PR is on top of #59778, because I think I can safely assume that will be merged first.

[KristofferC]

If possible, it would be nice to cut this up into some orthogonal pieces. For example, the AnnotatedString perf improvements could be a separate PR that (with benchmarks) could be merged and would make the diff here smaller and easier to review.

[kdheepak]

Maybe it should default write to a location? The prompt could default to ~/.julia/history.jl (or a more appropriate location).

---

Ideally, the prompt for the filename would also allow scrolling up and down with the up arrow and down arrow, typing some characters of the file and hitting up arrow to narrow the search, have a ghost text of the last file name or the default file name so right arrow completes it etc. But I can imagine this being awkward the way things are set up in the REPL?

[tecosaur]

Ideally, the prompt for the filename would also allow scrolling up and down with the up arrow and down arrow, typing some characters of the file and hitting up arrow to narrow the search, have a ghost text of the last file name or the default file name so right arrow completes it etc. But I can imagine this being awkward the way things are set up in the REPL?

I've had exactly the same thought. I just can't be bothered to make it happen 😅

[tecosaur]

If possible, it would be nice to cut this up into some orthogonal pieces.

I'm happy to split this up, but there are really just three parts to it:

1. A refactor to _replace_final (needed to reuse some code for annotation-preserving replacement)
2. Introducing support for annotation-preserving replacement (needed for changing multi-line annotated strings into single-line with linebreak symbols)
3. Replacing the old history system with the fancy new one

I could split 1-2 off into a separate PR to review, if that sounds like a nice idea?

the AnnotatedString perf improvements

There's only suspicious performance here, not perf improvements, unfortunately 😞. I say "suspicious" because if I remove the keyword argument from replace skip reconstructing a named tuple with a range shifed the total time of a small replace op drops from ~4400ns to ~200ns. Given that an equivalent annotation-less replace takes ~65ns a time of ~200ns would be decent I think, but ~4400ns is strange — I can't figure it out though. If I can interest anyone else in investigating, that would be great.

For now, I've left these REVIEW code comments:

julia/base/strings/annotated_io.jl

Lines 202 to 226 in cc7ed22

	# REVIEW: For some reason, construction of `newannot`
	# can be a significant contributor to the overall runtime
	# of this function. For instance, executing:
	#
	# replace(AnnotatedIOBuffer(), S"apple",
	# 'e' => S"{red:x}", 'p' => S"{green:y}")
	#
	# results in 3 calls to `_insert_annotations!`. It takes
	# ~570ns in total, compared to ~200ns if we push `annot`
	# instead of `newannot`. Commenting out the `_insert_annotations!`
	# line reduces the runtime to ~170ns, from which we can infer
	# that constructing `newannot` is somehow responsible for
	# a ~30ns -> ~400ns (~13x) increase in runtime!!
	# This also comes with a marginal increase in allocations
	# (compared to the commented out version) of 2 -> 14 (250b -> 720b).
	#
	# This seems quite strange, but I haven't dug into the generated
	# LLVM or ASM code. If anybody reading this is interested in checking
	# this out, that would be brilliant 🙏.
	#
	# What I have done is found that "direct tuple reconstruction"
	# (as below) is several times faster than using `setindex`.
	newannot = (region = start+offset:stop+offset,
	label = annot.label,
	value = annot.value)

julia/base/strings/annotated_io.jl

Lines 236 to 240 in cc7ed22

	# REVIEW: For some reason the `Core.kwcall` indirection seems to cause a
	# substantial slowdown here. If we remove `; count` from the signature
	# and run the sample code above in `_insert_annotations!`, the runtime
	# drops from ~4400ns to ~580ns (~7x faster). I cannot guess why this is.
	function replace(out::AnnotatedIOBuffer, str::AnnotatedString, pat_f::Pair...; count = typemax(Int))

[tecosaur]

I've just added back ~400 loc of the original code for using up/down arrow keys to go through recent history without ^R.

If you start a new REPL and immediately press up arrow, it does nothing the first time. Not quite sure why... (any ideas?)

I would like to add session-awareness. Maybe I'll try to drop that in this PR too?

[tecosaur]

Rebased to the latest REPL Syntax Highlighting HEAD.

[tecosaur]

Fixed some typos.

[tecosaur]

The precompilation situation is looking pretty decent, this is all I'm seeing with --trace-compile:

#=   19.4 ms =# precompile(Tuple{Type{Base.IOContext{IO_t} where IO_t<:IO}, Base.GenericIOBuffer{Memory{UInt8}}, Base.TTY})
#=   12.9 ms =# precompile(Tuple{typeof(Base.get), Base.Dict{Tuple{Symbol, Any}, Int64}, Tuple{Symbol, Symbol}, Int64})
#=   19.2 ms =# precompile(Tuple{typeof(Base.setindex!), Base.Dict{Tuple{Symbol, Any}, Int64}, Int64, Tuple{Symbol, Symbol}})
#=    2.5 ms =# precompile(Tuple{typeof(Base.print), Base.IOContext{Base.GenericIOBuffer{Memory{UInt8}}}, Base.AnnotatedString{String}})
#=    1.6 ms =# precompile(Tuple{typeof(Base._str_sizehint), UInt64})
#=    1.9 ms =# precompile(Tuple{typeof(Base.print), Base.GenericIOBuffer{Memory{UInt8}}, UInt64})
#=    2.5 ms =# precompile(Tuple{typeof(Base.AnnotatedDisplay.ansi_write), typeof(Base.write), Base.GenericIOBuffer{Memory{UInt8}}, Base.AnnotatedString{String}})
#=   14.6 ms =# precompile(Tuple{typeof(Base.getindex), Base.JuliaSyntax.GreenNode{Base.JuliaSyntax.SyntaxHead}, Int64})
#=    7.8 ms =# precompile(Tuple{typeof(Base.Terminals.cmove_up), Base.Terminals.TerminalBuffer})

[tecosaur]

Rebased now that #59778 has been merged.

[tecosaur]

If you start a new REPL and immediately press up arrow, it does nothing the first time. Not quite sure why... (any ideas?)

Fixed.

[tecosaur]

Thanks to Miguel, Camillo, and Sundar for taking this for a test-drive and providing feedback 🙂

Changes:

• Clarified that ; uses and logic in quick help
• Strip meaningless whitespace around filter segments
• Changed "negative" → "negated" search term
• Arrow keys (and others) no longer accidentally abort save
• Prevent runaway redisplays
• More minimal display updates
• Make mmap work on Windows

[tecosaur]

Rebase (get the REPL precompilation improvements)

[tecosaur]

• Add the (previously) bounds-error causing incomplete history as a test case
• Rebase to latest master

[tecosaur]

• Remember to reset history state after the new test

[rfourquet]

That's truly excellent!! Thank you!

I just started using it, and noticed a couple of problems:

1. I use a kind of numbered prompt, which breaks as soon as history search is first used, or on the second session prompt, by loosing a reference to the first history entry in the current session (presumably the .start_idx field of REPLHistoryProvider is reset to 1 or similar). A side effect is that, even without using a numbered prompt, the Alt-< shortcut brings you back to the first history entry ever, not the first of the session. This can be seen with the official numbered prompt:

2. I get an error when entering history search if my prompt_prefix is set to a function. The error is at
   runsearch(histfile::HistoryFile, term, prefix::String = "\e[90m"), whose prefix arg can only be a String.

[tecosaur]

• Rebase to latest master
• Fix a dodgy testcase
• Show $mode> in the preview
• Support prompt_prefix functions

[tecosaur]

• (hopefully) fix 32-bit CI

[tecosaur]

• Update the branch

[tecosaur]

• Prevent jitter when holding TAB at the end of a series of selected items

[tecosaur]

• I imagined that prompt_prefix took an argument

[rfourquet]

It seems you fixed the problem with keeping a reference to the first history entry in the session, great! But now it starts at 0, surely not acceptable for julia ;-)

(But maybe you again fixed it since yesterday)

[tecosaur]

It seems you fixed the problem with keeping a reference to the first history entry in the session, great! But now it starts at 0, surely not acceptable for julia ;-)

I did? This is (happy) news to me. That said, I never quite got to the bottom of why it wasn't working.

[KristofferC]

Let's merge this now so we get a "checkpoint" when CI is green and people can test it more, the remaining niggles shouldn't be a problem addressing post-merge.