I'm all for replacing readline. It's an ancient, very closely linked to the everyday experience of using the command line, and not very good. I want my REPLs to have things like syntax highlighting and decent tab completion UI, and readline has positioned itself to have a monopoly on the ability to implement these things but failed to deliver.
But this isn't addressing the real problem, which is that readline gets conjoined with the programs that use it. So if I want to write my own line editor, I have to significantly modify every program I want to use it in, which is enough of an obstacle that I won't do it (and neither will others). Nevermind more difficult architectural problems, like making editing local when on high-latency connections. Still, having a BSD-licensed line editor to start from may be helpful for whoever takes on that project some day.
there are a lot of forks of linenoise out there now.
this one looks good, but it's a big task to pick through all the divergent copies of the code and figure out which ones have genuine improvements and which ones are now rotting.
there's a rust one too which i recently added mingw/msvc support to. that's actually an example of how this splintering could be causing problems because we've just vendored some upstream version of the native c code and changes may be difficult to send back upstream.
That is one of the reason, why I renamed it the LINENOISE NG. The interface is compatible with the original LINENOISE, but it works on linux, Mac and Windows and it supports UTF-8.
(The original authors should have made the header comment "against the idea that a line editing lib needs to be 20,000 lines of C code, or any quantity of C++".)
These changes are in a different direction. I don't have windows or UTF-8 support, though. I started a branch to convert it to use wchar_t. Maybe I can cherry pick some things out of NG.
There are even a lot of other OPEN SOURCE projects with licenses (Apache, BSD) which cannot use readline because of their restricted GPL (instead of LGPL).
Well, this isn't correct, it's just that the result would have to be distributed under terms of GPL.
(Assuming the license is GPL compatible, which most of the ones you mentioned are).
This project goal is a bit more about replacing readline, but a big motivation for the original project is minimalism and trivial embeddability. It's all in the README.
While replying to this thread, my browser keeps autocorrecting "readline" to "deadline". So a case where technology makes us write correctly spelled nonsense :).
But this isn't addressing the real problem, which is that readline gets conjoined with the programs that use it. So if I want to write my own line editor, I have to significantly modify every program I want to use it in, which is enough of an obstacle that I won't do it (and neither will others). Nevermind more difficult architectural problems, like making editing local when on high-latency connections. Still, having a BSD-licensed line editor to start from may be helpful for whoever takes on that project some day.