Re: Colour support in editline

[christos%zoulas.com@localhost (Christos Zoulas)]

On May 12,  3:04pm, mejedi%gmail.com@localhost (Nick Zavaritsky) wrote:
-- Subject: Re: Colour support in editline

| Hi!
| 
| > Why are you assuming that people are going to pass ansi escape sequences =
| only?
| > If we assume ansi strings the problem becomes much simpler. We can hard-c=
| ode
| > a lot of the editor code and stop using terminfo for example...
| 
| 
| Thank you for the valuable insights. Apparently I didn=E2=80=99t realise th=
| e complexities.
| I will take a look into it.
| 
| Unfortunately it looks like it=E2=80=99s going in the direction the project=
|  I=E2=80=99m affiliated with isn=E2=80=99t
| particularly interested in :(
| 
| We probably need just VT100 support. Maybe liblinenoise is a better option =
| for us.

Well, don't give up yet :-). What I am proposing is not that hard to do.
We just need to come up with a design. Here are some preliminary thoughts:

1. We want to be able to use terminal attributes to make the prompt (or
   the input) look different. These can be colors, or bold, italic, inverse,
   dim, blink, whatever. It would be nice for users to be able to specify
   those logically as opposed to hard-coding escape sequences. We should
   come up with some syntax to do this (tcsh uses %foo bash uses \foo IIRC).
   There should also be a way to pass raw escape sequences to handle things
   like x-term title etc.
2. To do all that we need to have a way to mark characters in the prompt
   or in the line as "zero-width". Someone suggested to look how curses
   does it.
3. Should there be a way to query what abilities are available? When something
   is not available, then we just substitute nothing (takes no effect).
4. What to do with colors? We could hard-code the primary ones (by name?).


christos