Re: readline questions

[Chet Ramey]

On 10/8/21 12:37 PM, Christoph Anton Mitterer wrote:
> Hey Chet.
>
> On Fri, 2021-10-08 at 12:18 -0400, Chet Ramey wrote:
> > This is as you discovered: if ESC is part of the set of characters
> > that
> > terminates an incremental search, it will terminate the search.
> > Readline
> > doesn't attempt to read far enough ahead to determine whether or not
> > the escape sequence resolves to a key binding for reverse-search-
> > history
> > or, say, backward-char.
>
> I guess it wouldn't possible to have something like that implemented?

Anything's possible. The question is always whether or not the
implementation is worth the feature benefit.

> Seems that prohibits a number of key sequences that could be quite
> handy. Or it could also be nice to differentiate between <Shift> / no-
> <Shift> or maybe even left/right <Control> and so on.

Maybe not as many as you think. Readline uses the terminal driver to
get its input, and you'll only be able to differentiate between shifted
and non-shifted characters if the terminal emulator emits different key
sequences or that. For instance, my macOS Terminal doesn't distinguish
between shifted and unshifted up-arrow and down-arrow by default.

> > Readline only looks at the value of LS_COLORS when it first
> > initializes,
> > not on every call. It treats those colors as session-persistent.
>
> I guess that happens on the first prompt being printed? But probably
> still after PROMPT_COMMAND is executed the frist time? Cause otherwise
> I could use that as a hack to set the "normal" LS_COLORS afterwards.

Yes and yes. Think of it in terms of a different application, since
readline runs in a ton of applications besides bash. Readline parses
LS_COLORS the first time readline() is called to get a line of input, and
not after that.

Readline doesn't have anything to do with PROMPT_COMMAND itself, so that
shell-specific action happens immediately prior to each time bash calls
readline().


> > Should I move it to the initialization that's done on each call to
> > readline()?

> Hmm no,... I think the best would be to make the colour simply
> configurable as I've asked for over at the readline mailing list. 

But that's a different question. It's possible that users might want to
see changes they make in LS_COLORS reflected in the colors they see during
completion. Not a lot of applications allow you to change environment
variables while they're running, but bash does.

The primary thing that's holding me up is that no one has ever written
code to deallocate the resources parsing LS_COLORS creates (or if they
have, I didn't find it after a quick search), so I'd have to write that
myself. I've not done it.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/