Re: Colour support in editline

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

In article <CAAYXoE8TC_r+LkFAfiNz1uyNTWdMdL+-yynFcb-PXx8kB7YzFA%mail.gmail.com@localhost>,
ZNV  <mejedi%gmail.com@localhost> wrote:
>-=-=-=-=-=-
>
>Hi!
>
>Is there any interest in adding colour support to editline?
>
>It is a known issue that editline doesn't support colour prompts.
>http://stackoverflow.com/questions/21240181/how-to-colorize-the-prompt-of-an-editline-application
>
>We are also interested in some editor-like features, including syntax
>highlighting and
>matching parens while typing. Those are probably of a little interest for
>the general audience,
>however once the machinery necessary to enable colour prompts is in place
>these editor-like
>features almost come as a side effect.
>
>I was able to implement colour support on top of a dated editline source
>tree:
>https://github.com/mejedi/libeditline-color
>
>While it works, I'm not exactly happy with the patch. I was concerned with
>merging
>with the upstream, so I tried hard to avoid extending core data structures
>like el_(v)display.
>The code is still working with Char pointers, but here and there the
>associated colour
>data is retrieved in an awkward way.
>
>So if there is any interest in colour support in editline, I am willing to
>rework my patch and
>to collaborate to make it happen.

Yes, there is interest, but it should be done correctly. Currently this
is difficult because the marker hack to indicate the beginning and the
end of an escape sequence so that it is not counted as a cursor position
does not work properly. Instead it should be replaced with something that
works (perhaps an adjacent data structure that holds pointers to ANSI
escape sequences or NULL for each character position in the line. That is
memory expensive, but easy to implement.

christos