Principal support for colored prompts.

[phmarek]

Sadly, see this bug report: https://mail-index.netbsd.org/netbsd-bugs/2013/02/06/msg031942.html and this description: https://stackoverflow.com/questions/21240181/how-to-colorize-the-prompt-of-an-editline-application

This is still true as of now - multiple escape sequences like with PS1='[\e[1;34m][\u@\h:\w]$[\e[0m]' are broken, and a single pair like in PS1='[\e[1;34m\u@\h:\w\e[0m]# ' isn't feature-complete.

We'd need to get rid of editline...

[SquircleSpace]

I'm confused. You're saying colored prompts aren't possible. What does this PR enable, then?

I'm fine with dumping editline. A few weeks back I started looking at a pure-lisp editline alternative: https://github.com/sharplispers/linedit. It looks promising, but we may have to figure out how to get it to play nicely with SHCL's fd-streams.

[phmarek]

Well, if you plan to use libreadline, then this needs only minor modifications. When dumping editline it makes no sense, unless your linedit (really only one "e" in the middle?) needs similar tricks to keep special sequences. (The idea after marking these is that the number of characters left in the current line can be counted.)

[phmarek]

And principal meant that

PS1='[\e[1;34m][\u@\h:\w]$[\e[0m]

is broken, but

PS1='[\e[1;34m\u@\h:\w\e[0m]# '

works (but is actually wrong). Ie. escape sequences for colors work, they only need a workaround for the broken editline behaviour.

I posted the patch because I only found that out after implementing it... (of course ;)

Further on, perhaps we want to prefer $PS1SHCL over $PS1 and/or prepend or append "shcl" somewhere - that would be less confusing ;)

[SquircleSpace]

Unless you have a different readline in mind, GNU readline is licensed under the GPL. I'm trying to keep SHCL covered by a permissive license. So, I wouldn't want to completely abandon editline in favor of readline. However, there's no reason we couldn't support both readline and something else!