Re: could there be a bash built-in that allows executing readline functions?

[Chet Ramey]

On 10/24/23 3:16 PM, Christoph Anton Mitterer wrote:
> Hey.
>
>
> On Tue, 2023-10-24 at 12:06 -0400, Chet Ramey wrote:
> > If there were a key binding that was, by default, bound to something
> > like execute-named-command, wouldn't it be the user's responsibility
> > if
> > they bound it to something else?
>
> I would say that for the \ec I've used in my examples - that is the one
> where the user says: use that keyseq to run that widget in my bash.
>
> But not for any helper keyseqs that are in principle only needed
> internally.

I would not say they are internal. Transient, maybe. Temporary, maybe.
But they modify a shared global resource (the current keymap).

> Sure, we can now simply define the others as being in the user's
> responsibility, too. But I don't think it's feasible for the user in
> the real world to check all these things.

I wonder if this is an opportunity to add an option to bind that takes
a key sequence and displays the name(s) of any function(s) it's bound to.
Then your code could check whether or not a key sequence was bound and
take whatever action you want.

> Take the example of fzf's integration scripts:
> - They use the \e[5n -> \e[0n trick, but there is no warning anywhere
>    that this is needed. And let's be honest, even if there were, how
>    would care?
> - They also assume numerous other keyseqs to be in their default state:
>    
> https://github.com/junegunn/fzf/blob/b1a0ab8086f061640948299b9ed90a6b0c61c143/shell/key-bindings.bash#L131

So they make assumptions you're not willing to.


> > >     That it works itself (and doesn't break anything else) depends
> > > fully
> > >     on the likeliness that one uses keyseqs that no-one else use.
> >
> > How likely do you think this is?
>
> If I were to use \e[5n it seems already quite likely (e.g. fzf uses it
> too) and if I'd follow Koichi's recommendation of using invalid
> overlong UTF-8 encodings,... well it seems still somewhat possible.

Your choice.


> > Let's conduct a thought experiment. Say I added some new option to
> > `bind'
> > for this (this clearly does not deserve its own builtin). Under what
> > conditions should it execute? What should it assume about readline's
> > state or the state of the objects readline exports (line buffer,
> > etc.)?
> > The executing part is easy: take a string, look up a function, and
> > execute it.
>
> Uhm, difficult to say. As you may have noticed, I'm far from being a
> bash/shell expert.
>
> I would have naively assumed it to be similar like bind -x ... just
> that it doesn't set up a new binding but execute either a keyseq macro
> or a readline function.
> So let's call it bind -e (for "e"xecute macro/function).

Sure.

> So presumably it would also see the READLINE_* vars, just as the code
> from -x does? 

Why would you assume this? This is a general mechanism to call a readline
function, and readline functions operate on an existing readline line
buffer, just as if it were invoked by a key binding.

> And if called via -x (as it would be the case in my
> example) it would of course see the READLINE_* from that (which is
> anyway the same).

Yes, those variables would be in the shell environment, but an internal
readline function would never modify them.

The READLINE_* variables are an application-specific way for an application
using readline (bash) to communicate changes back to readline about changes
to the internal line buffer it uses made by a bindable command. This
function (the one installed by bind -x) is, from readline's perspective,
just another bindable function that may modify that line buffer. The
internal readline functions that this new option would execute would
operate on the internal readline line buffer as they always do.


> It would also see any other bindings as they are at the point of being
> executed.
> So I guess when one would execute:
>    bind -e "foobar"
> it would be as if someone just typed foobar (obviously one would need a
> way to differentiate between macros and functions).

No. This is a way to execute a named command as if it had been bound to
a key sequence and the key sequence had been read from the input. What
you're asking for here is a way to stuff input so that it will seem to
readline like it had been read from the input. I'm not considering that
at this point.

> > But how do you want to guarantee it executes on something
> > reasonable?
>
> You mean when this would be executed e.g. from a script and there is no
> readline? Uhm not sure...
>
> Aren't there two things?
> 1. executing some macro, like the \xC0\a\xC0\r\xC0\n

We're not talking about this.

> 2. executing some readline function

We're talking about this.


> (2) would then probably only make sense if one is either live on the
> readline OR while executing bind -x code?

So you can figure that out from the readline state. (And both of those
cases are `live' on readline.)

> But perhaps there are people with uses cases that want that to
> be queued up for until the next time readline is back in control?

I'm not really interested in doing that either. It leads to all sorts of
state management issues.

> On Tue, 2023-10-24 at 14:32 -0400, Chet Ramey wrote:
> > Should this mode run multiple readline commands per invocation?
>
> I'm not sure whether I understand this.
> You mean that I could do in the case (2):
>     bind -e "accept-line, redraw-current-line"

Close, but not quite. You would treat each remaining argument to bind as
the name of a readline command to execute.

It would be interesting to see how executing accept-line, which causes
readline to clean up and return the line to its caller, would interact
with the remaining code in a bindable function. My guess is not well.

--
``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/