
Linenoise - A minimal, zero-config, BSD licensed, readline replacement - skorks
http://github.com/antirez/linenoise
======
spicyj
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.

~~~
hga
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.

~~~
spicyj
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!

~~~
hga
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 ^_^.

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

------
imurray
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/>

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

~~~
antirez
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.

~~~
ZeroGravitas
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.

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

------
tlrobinson
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.

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

~~~
antirez
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.

~~~
DuClare
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.

