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.
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 ^_^.
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.
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.
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.
* 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.