Re: Access to readline completions without line editing

[Spencer Baugh]

Chet Ramey <chet.ramey@case.edu> writes:
> 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.

Ah, so you're saying that an API where Emacs sends the text to complete
and a position within the text would have too much overhead because
setting up and tearing down a line buffer is too expensive?

Alternative idea: what if we just reuse the existing main line buffer?
We could have an API for Emacs to send text and a position within the
text, which would replace whatever is currently within the line buffer.
Then we would have a separate API to trigger completion and output
completions in a structured form (as described below, maybe just writing
them to /dev/tty)

Although I suppose replacing the contents of the current line buffer
could be done by just:
1. Run with INPUTRC=/dev/null to get default bindings
2. C-u to clear before the cursor
3. C-k to clear after the cursor
4. Send the desired text
5. C-b back until we hit the position we want

Does that seem like a reliable way for Emacs to clear the line buffer
and replace it with specified text?

>>>> 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.

A list of possible completions given the current contents of the line
buffer, you mean?  Yes, that sounds reasonable.

Could we add a function which does that?  And possibly bind it by
default to some obscure control code which a user can't actually input?
Then Emacs can send that code and parse the response to display
completions.

Although, some issues:

- Could we mark the start and end of the list of completions with some
  special characters or escape sequences?
- Can we be sure the list of completions won't be mixed with other
  output from the application using readline?
- Can completions contain newlines?  If so, maybe we'd want the list to
  be null-delimited instead?  But if it's null-delimited then I think
  we'll run into TTY line length limitations, very annoying.