Re: Access to readline completions without line editing

[Chet Ramey]

On 10/3/23 5:41 PM, Spencer Baugh wrote:
> Chet Ramey <chet.ramey@case.edu> writes:
> > On 10/3/23 3:50 PM, Spencer Baugh wrote:
> >
> > > > If you want to disable readline, then readline won't have any access to
> > > > the line editing data, and can't really do anything.
> > >
> > > Yes, I said this badly.  readline would be enabled, since we'd be using
> > > completions from it.  But Emacs would handle displaying the available
> > > completions - somehow they would be communicated from readline to Emacs.
> >
> > So readline would be reading the input and managing its line buffer?
> > Otherwise, how would it know the text to complete? Or are you suggesting
> > an API that takes the text as an argument?
>
> Either works.  An API which takes the text and a position within the
> text as arguments would be more general and probably work better for
> Emacs, but it might be a bit complex to communicate those arguments to
> readline from Emacs.  But I'd be happy to work on it.

The added complexity of setting up (and then tearing down) a new readline
line buffer containing that text, since that's where application completion
functions know to look for it, is probably too much.

> (To be clear, I'm abusing the term "API" a bit - I mean any kind of way
> for Emacs to talk to readline, including by sending control codes on a
> tty or messages on a pipe or things like that; not necessarily linking
> against readline and calling C functions)

"Control codes on a tty" is just another way of saying a readline key
binding. But it's clear that if Emacs wants to initiate this out of band,
there would have to be some other way.

> > > That's why it would be nice to have an API to ask readline to trigger
> > > completion, including application-specific completions.  Since those
> > > completions are often not available any other way.
> >
> > There are already APIs for this. It depends on what you want the end point
> > to be.
> >
> > For instance, you could write yourself a wrapper function that temporarily
> > sets a display-matches hook, calls rl_complete_internal('?'), and gets
> > the list of matches to display. There is a single complicating factor to
> > this in that, under some circumstances, the display-matches hook will not
> > be called if there is only a single possible completion, but we can figure
> > out something for that. You could even bind it to a key sequence.
>
> Yes, that kind of thing would work!  But specifically I think we'd want
> something that exists in upstream readline, so that Emacs (or other
> wrappers) can fetch completions for any readline-using application,
> without having to modify each individual application.
>
> By end point, do you mean the destination where the completions are
> sent?  There are a bunch of possibilities, but one approach that might
> work: Maybe we specify a file path, or file descriptor, with an
> READLINE_STRUCTURED_OUTPUT environment variable.  And the completions
> would be sent there, as a null-terminated array of null-terminated
> strings, or something.

Maybe just send a list of possible completions, one per line, to
/dev/tty.

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