libedit probably not a suitable replacement: https://github.com/conda-forge/python-feedstock/issues/387
> OK, let me rephrase, then. I am that person. I work on some other projects > that use readline/libedit. I can tell you that it is a huge headache, even > on Mac, when libedit is used instead. This is because libedit only > partially implements the readline API. It is not 1:1 and many APIs are > missing. It causes tons of issues for users & developers who have a really > hard time figuring out what went wrong. It really doesn't make sense to > treat them as equivalent. > > In terms of specific missing functionality, it has been a couple of years, > but I believe it was a lot of stuff related to tab completions, and that > libedit doesn't respect the full key-binding syntax that readline has. > mruby might have been overlooked, but better safe than sorry? https://github.com/conda-forge/conda-forge.github.io/issues/209 > Basically, it boils down to: "is the code running in the same memory space > as other GPL code". > > However, if your program is compiled with the readline library for > example, certain binaries in that package have included material portions > of code protected by GPL. > > You can use ldd to check for yourself. If a library is linked to GPL > code, it is GPL. > If you find that a library is linked to GPL code, then by definition > (GPL-v3, clause 3), that particular instance of the compiled library is now > protected by GPL. And as such, you must abide by clause 3, which means you > must give > a) Give prominent notice with each copy of the object code that the Library > is used in it and that the Library and its use are covered by this License. > b) Accompany the object code with a copy of the GNU GPL and this license > document. > > Would linenoise be another possibility? https://github.com/antirez/linenoise > A minimal, zero-config, BSD licensed, readline replacement used in Redis, > MongoDB, and Android. > > - Single and multi line editing mode with the usual key bindings > implemented. > - History handling. > - Completion. > - Hints (suggestions at the right of the prompt as you type). > - About 1,100 lines of BSD license source code. > - Only uses a subset of VT100 escapes (ANSI.SYS compatible). > > On Sat, Nov 21, 2020 at 8:23 AM Alexander Burger <a...@software-lab.de> wrote: > Hi all, > > at yesterday's PilCon it turned out that pil21 has a serious licence > problem. > > A major design decision of pil21 was to use readline(3) instead of the > self- > rolled @lib/led.l from pil64/pil32. > > The reason was compatibility with the rest of the world (readline supports > both > vi- and emacs-mode right out of the box, uses the same ~/.inputrc as bash > and > other tools, and everybody is used to it), and high configurability. > > > I took a look at editline() / libedit. Very different API! It does not > even use > ~/.inputrc but requires a separate ~/.editrc. > > I don't see that it supports all the features pil21 needs (hooks to various > functions for signal handling, background tasks and display control (see > pil21/src/lib.c). > > > Better go back to GPL with pil21? > > I'm getting fed up with these licence wars! > > ☹/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe > >
