libeditline

Disclaimer: forked code

• The original project appears, sadly enough, to have been abandoned. The authors left no email addresses in their source code, no README file, no web site, etc.
• The project on Sourceforge is hosted by someone other than the original authors, he hasn't made a release some 3.5 years, has no code in the CVS tree, and so far attempts to contact him have failed. (However, the fact that some 1500 people have downloaded the sources from the SF project show that this code is something people want!)
• This code fills a massive niche which i've needed to fill for a long time (3+ years), and it's not readily available in an overall-useful form on the web. i'm gonna get a LOT of use out of it, and want it readily available (and readily hackable!). :)
• i've made a significant number of changes to it, and don't have an originating project i can submit them back to.
• Googling for libedit brings up remarkably little - mostly people talking about it, but nobody hosting a copy of it or information about using it. (i personally found it by accident via a link in the PHP documentation for its Readline extension.)
• It's good, useful code (at least, it was before my changes ;), apparently has no home, and deserves some evangelism!
• It is the only known implementation of a readline-like library which does not fall under a restrictive license (yes, the GPL is restrictive), and it would be a damned shame to see it fall between the cracks of the internet, so to say.
• As a C++ coder, i need this code and, as a license holder, i'm gonna exercise my rights . ;)
• And, lastly: as a user of a library, if the mainstream code base isn't readily available/hackable, it's time to Use the Fork, Luke! (Sorry, it had to be said. ;)

Getting it...

Significant changes from the original libedit

• The readline-compatibility-mode header has been renamed from readline.h to editline.h, for reasons explained in the README.
• The library name has changed from libedit to libeditline, for reasons also explained in the README.
• The tree, as shipped, compiles the lib as C++, not C, because i only link it against C++ code and the sources don't have the extern "C" blocks which they need. Forcing it to compile as C++ is a workaround so i can link against C++ client apps.
• el_gets() no longer returns a trailing newline, even when not in readline-compatibility mode. The old behaviour was, IMO, brain-dead, intrusive on client code (who always had to remove the newline or work around it), and counter to every convention known to computer science (with the exception of perl's while(<>){...}, and that doesn't count because the first command in such a loop is normally chomp, to remove the newline!).
• There have been a huge number of (char *) to (const char *) changes, to help clarify pointer ownership on function parameters and return values, and to ease an eventual port to std::string.
• In readline-compat mode, builtin functions are now swallowed by the readline compatibility layer, executed via libeditline but not propagated back to the client (there is no need for them to see them, IMO). Even though the client app will not see these events/inputs, they are added to the command history, for usability reasons (this also coincidentally helps keep the history in sync with client-side history management).
• Builtin commands now all have a prefix of "el-", for reasons explained in the ChangeLog.
• Builtin functions may now be added from the client-side, via el_register_builtin(), and clients can query the list via el_builtin_by_name() and el_builtins_list().
• Some of my changes (e.g., builtin function handling) are implemented in C++, not C, to simplify some code by using, e.g., standard containers. i have avoided using "complex" C++ features (e.g., templates) which might cause problems for older compilers - in theory the C++-related changes will even work on gcc 2.95.x (but this is untested/unproven). Also, so far i have used only C-aware data types in the public APIs (though this might change in the future).
• i'm slowly adding documentation to the API (which i've largely had to decode, due to non-existent, ambiguous, or simply non-informative docs from the original authors). There is a man page, but it's quite incomplete, and doesn't currently cover any of the mutilations i've done on the API.
• Replaced the several of the #defines with more descriptive/usable names. e.g., the 3 macros public, private and protected were changed, for obvious reasons, by adding a prefix of el_ to each. (i still cannot BELIEVE someone defined those as macros!)
• Default editing mode is now emacs, not vi :). (Sorry, guys! Deal with it!)
• In readline compat mode, you can call el_readline_el() to get el's internal EditLine object which is used for readline compatibility mode. This means you may directly customize it using the el API, which wasn't possible using the original release.

Caveats and known problems

• Has little usable test/sample code. The test app which shipped with the original tree (now under ./test/test.c) is quite buggy, apparently due to its internal handling of continued lines. It sorely misrepresents the core lib as being buggy (which does not appear to be the case at all).
• Emacs-style incremental searches work a bit differently than in emacs/readline: you've got to play around with them a bit to figure out how it works (but it does work).

Porting from GNU Readline, mini-HOWTO

• See editline.h for the full list of "compatibility functions". Most commonly-used readline functions are emulated there, including the history-related API.
• Change #include <[readline/]readline.h> to #include <[editline/]editline.h>. If you have included history.h, remove it - those are covered by editline.h. If you don't use any of readline's signal-handling functions (like the SIGWINCH stuff) then you're done!
• If you use readline's signal handling functions, comment them out, #if them out of existence, or otherwise get rid of them - you won't need them any more.
• Link against -leditline -lncurses (curses is used by both readline and editline, by the way).

Hacking editline

Potential TODOs

• More C++!!! i want to port most of it away from ([const] char *) to std::string, at the very least. There's a LOT of stdup()ing going on in the code, and that makes me nervous. This is a major undertaking, however, and will probably require a day or three of Zen Coding Session(s). The relative cleanliness and modularity of the underlying code should ease this port significantly, though.
• Write an OO wrapper for the editline type, eventually completely replacing the current struct with an OO class.
• Improve the "readline compatible tab completion handler" a bit. It isn't quite as compatible as i'd like (try entering /bin/[TAB][TAB]), but all in all it's quite okay.