Re: [RFC] edit: Add basic support for input line editing

Hi Grant,

>> This allows for simple line editing with history capabilities. On
>> purpose this has no concept of terminal input or terminal output and
>> just allows manipulation of an internal wide character string.
>> 
>> The history storing and loading is currently missing, but would be easy
>> to add. The other two items are missing completion and hints handling.
>> 
>> This feature is not yet complete, but good enough for a first review and
>> a sample application using it in a curses environment will follow.
>> 
>> The debug option is something that might need to be removed or at least
>> changed a little bit, but right now it is nice to see the internal
>> states.
> 
> 
> Any reason not to build on / improve linenoise or to put a neutralizing wrapper around libedit / readline as ntp did / does?
> 
> Each have their deficiencies, of course. However, it seems like, at least linenoise and libedit are close enough where a delta would be smaller than a rewrite-from-scratch.

so funny that you asked. I actually started with linenoise and was going to just use that. While it looked promising, it did not work out. I have written a whole integration with it and was initially really happy. However the problem is that linenoise (and others like ccli etc.) are based on the concept of direct access to the TTY and sending/parsing ANSI sequences. That is all good and golden, but doesn’t fly if you want to work in a Curses application. I learned the hard way that Curses and ANSI sequences don’t go together at all. And with the Curses idea, the direct access to stdout from linenoise is also not functional. I worked out a few things and still thought that I just extend linenoise until I started to play with umlauts and Unicode and then I hit a really hard brick wall.

This caused me to re-evaluate the basic idea on how all line editing libraries are done right now. So l_edit has no direct input/output capabilities. That is up to the caller. I removed prompt handling on purpose since the caller can do that better than the line editing library. And I also removed masked support (which I had initially) since the caller again can do that way better.

I do have a Curses based demo that will show this, but it is too messy at the moment to publish. I will clean that up and then maybe this becomes a bit clearer why this approach is better.

While doing this, I also found new respect for readline, but that thing has to go since its insistence on GPLv3 is just causing long term problems.

Regards

Marcel