Recently I was reminded that lack of line editing in the nix REPL has been a constant low level obstacle for years now, by this thread: Vi mode in Nix repl
As mentioned there, it seems like adding readline would not be hard, but the fact that nix chose libeditline implies it was an intentional decision, but I can’t find any discussion or documentation about it. Before I add readline, does anyone know the history? Also in the spirit of the “where did you get stuck” topic just posted, would a PR be rejected or ignored? My usual process is to add a company-internal local patch and move on, but that thread triggered some kind of idea of community spirit.
4 Likes
I don’t have any firsthand knowledge here; just looking through history and pulling threads…
-
It looks like readline was replaced with linenoise in 2017 due to a license issue and to reduce the footprint by avoiding ncurses:
Replace readline by linenoise · NixOS/nix@c5f23f1 · GitHub
-
linenoise appears to have had its own licensing issue that resulted in editline replacing it within a year:
-
It looks like very basic support for building w/ readline was readded not long after, but that there’s some reluctance to actually maintain two sets of code there:
1 Like
Thanks for that research. I had naively assumed that they’re all GPL so equivalent but of course there are different incompatible GPL versions… but I don’t really understand the implications. In any case, it doesn’t seem to be the real show stopper because people were adding it back. If the real problem is too much code to maintain, that is really saying “we don’t want it”, I’ll do an internal patch.
I don’t agree with the priority though, for people who are used to vi-keys, the current situation is equivalent to no line editing, with the notable exception of tab completion. That in turn means the easier workflow winds up being to write expressions in a separate window and copy paste them over. That has its own advantages, but is still not a great experience for the main UI of the language.
But that makes me think, perhaps a better avenue would be search for or write a vim extension that can pipe a selection to a REPL, much like the emacs people have presumably been doing forever. Even if that does work out, it’s still not as good has having both “pipe to REPL” and good line editing.
4 Likes
Please make the patch public if you make it.
I would use vi binds in repl 
3 Likes
It’s also been several years; it’s possible opinions have changed. (The Nix team has, AFAICT, been doing a good job recently of getting issues/PRs slowly triaged. It may be slightly easier to get this on the docket than in some years previous…)
This is a completely naive take since I’m not at all familiar with the code here, but I also wonder if it’s something where they’d be more open to making it extensible or modular to encourage re-use (since that might meet the apparent goals of keeping ncurses out and keeping the core from accruing a bunch of conditional editline/readline code.
1 Like
It should depend on how hairy the readline support is and how often repl.cc changes. From the old patch it looks like readline is a bit more hairy than I suspected (e.g. the longjmp stuff for ^C) but still pretty reasonable, and repl.cc so rarely changes that maintenance seems like a non-issue.
I’m skeptical that ncurses is a serious liability, everyone else uses it just fine, even though we’ll evidently have 5 and 6 forever. But, I’ve been surprised before by the things that cause problems and nix has a bootstrap problem with its initial install. Still, how many people install python? A bit more than nix. In any case, I’d be fine with it turned off by default. It turns out we have an elaborate system specifically designed to parameterize and rebuild software!
3 Likes