Linenoise - A minimal, zero-config, BSD licensed, readline replacement | Hacker News Reader

Linenoise - A minimal, zero-config, BSD licensed, readline replacement

github.com

83 pointsskorks19 comments

Looks really nice. I'm just being nitpicky, but in case antirez is hanging around:

* Ctrl-B seems to make the cursor go forward, instead of backward. * Ctrl-T could transpose two characters, but also goes forward. * Ctrl-P/Ctrl-N could act as up and down arrow keys, too.

And I'm not sure if Ctrl-D should do anything by default, but I pressed it instinctively expecting it to close the (example) program.

Hello, thanks spicyj, I'll try to get this fixed asap.

I'm not too familiar with readline, but traditional EMACS behavior is for ^T to drag a character forward, and only transpose at the end of a line.

And thanks a LOT for writing this; as I'm sure you know, the GPLed readline has caused a lot of heartburn for years and years.

Depends on what your definition of transpose is. I guess I always just looked as it as transposing the characters to the left of and to the right of the cursor and then moving the cursor right, which I guess is dragging a character forward. You learn something new every day!

They're of course the same thing, I just found the mental model of dragging forward to be simpler (in either model you still have a special case for the end of a line). I may have had someone point this out to me, I learned EMACS in 1980 and half my professional work in the '80s was on various UNIX and LISP versions of EMACS.

And it adds to your editing toolkit, you can not only transpose two characters, you can also drag one a few positions forward, which for the way I (mis)type is useful ^_^.

Just pushed all the suggested changes. Thanks.

FWIW, this is from the guy who brought us Redis.

Interesting. It's frustrating when using programs with terrible line editing support because they've rolled their own. Hopefully this will work out well and then be widely adopted by non-free and smaller projects for which readline has been rejected.

rlfe [1] is a wrapper that allows "any" program to use readline. At one point I hacked this so that I could get decent line editing in Matlab [2]. Matlab is particularly bad for inputs longer than a single line. The problem is that I then lost the native tab-completion support in Matlab and gave up.

[1] http://per.bothner.com/software/#rlfe — Debian package available, and presumably for some other distros too.

[2] http://www.cs.toronto.edu/~murray/code/rlfe_matlab/

rlwrap does the same thing (and very well too, I might add).

Hello danh,

actually rlwrap and readline are not doing at all the same thing, but are instead solving the same problem. In fact rlwrap uses readline itself in order to wrap another executable missing line editing support.

Linenoise instead is intended to be an alternative to libreadline itself in order to provide built-in line editing capabilities.

I believe danh is saying that rlwrap does the same thing as rlfe, another readline wrapper mentioned in the post above, not that linenoise is just a wrapper.

Ooops, indeed, sorry for misreading.

That is indeed exactly what I meant. Sorry about the ambiguity.

Yes.

On the other hand readline has brought more than one program into the realm of the GPL, so they certainly achieved some of their political goals.

Neat. I'm surprised this hasn't been done before (assuming it hasn't)

One feature I like about rlwrap is the persistent history.

It might be nice to build this into Linenoise as an option, rather than having to roll your own for every tool you use it on.

Antirez: if you think it's a worthy feature I might be willing to submit a patch. I think I might use this for the Narwhal and Objective-J REPLs.

MRI is looking for a replacement for readline because of its GPL license. How does Linenoise work with Unicode?

Just tested, at first it appears to work without issues. I think the problem can arise if some encoded unicode char looks like an escape char or other key combination, don't know if this is actually possible or not.

It doesn't work without issues at all. It's going to calculate the width of the string wrong, so the pointer movement is all broken: enter some utf-8 characters, move a "character" backwards - boom, your pointer is in a funny place. Once you move past the excess "space" (which is there because the code assumes 1 character=1 byte), you're going to tap multiple times to see the cursor go past a single character. Delete a character (byte) and watch it turn into something else.

There's no unicode support at all.

I also miss a lot of features most would take for granted in a line editor. Deleting and jumping between entire words, simple (or not-so-simple) history search are just a couple common and useful features.

Right, this is not compatible with readline, so people can't use it as a fallback. Now who's going to depend on a 400sloc library only to get a prompt and forward/backward & line-wise history movement with hardcoded non-personalizable bindings? Surely one can do that in seventy lines? ;)

You've got a lot of code to write; the line editing capabilities of the common libraries aren't as minimal as some may think. Of course you can just ignore all of it and say that other people don't need these features because you never used them.

Having said all that, I don't have anything against the idea of seeing another BSD-licensed line editing library prosper. If you want to do it, go for it! If the basic features get there, I'll embrace the project. In the meanwhile, I'll sit back and promote libedit.

I think you would use 'editline' for that, no? This is more a minimalist/default/configure can't find anything else solution.

Reply on news.ycombinator.com