Re: Access to readline completions without line editing

[Spencer Baugh]

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.

(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)

>> 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 we could even case on the presence of READLINE_STRUCTURED_OUTPUT
in the environment, and only make some new key sequence or API available
when it's present.