Re: Access to readline completions without line editing

[Chet Ramey]

On 11/18/23 9:19 AM, Spencer Baugh wrote:
> 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.

OK, see below.

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

The application can do this.

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

I just added a bindable command named `export-completions' that does this.

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

The bindable command uses the existing line buffer and performs completion
from wherever point is, just as if the user typed a TAB.

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

Here's the format I decided on. My intent is that it's general enough for
applications besides emacs:

/* This implements a protocol to export completions to another process or
   calling application via rl_outstream.

   MATCHES are the possible completions for TEXT, which is the text between
   START and END in rl_line_buffer.

   We print:
        N - the number of matches
        T - the word being completed
        S:E - the start and end offsets of T in rl_line_buffer
        then each match, one per line

  If there are no matches, MATCHES is NULL, N will be 0, and there will be
  no output after S:E.

  Since MATCHES[0] can be empty if there is no common prefix of the elements
  of MATCHES, applications should be prepared to deal with an empty line
  preceding the matches.
*/

The bindable function (rl_export_completions) takes the same two arguments
as any other readline function (count, key), and will clear the readline
line buffer if count > 1.

This was inspired by a message sent to me privately; the sender described
the intended use case as:

"Emacs activates this capability by making and passing in a custom
inputrc that binds `send-completions`, then uses it by sending the text
of the line being completed over, navigation commands to move point to
the right location in the line, and the key bound to `send-completions`.
Emacs then parses the output to get the boundaries of the word being
completed over and the list of completions, which it can use to render
the completions and allow choosing between them in an Emacs-native way."

The documentation I write for this bindable command (I haven't finished
it) will be in the next push to the bash devel branch, and, sometime
after that, the next push to the readline devel branch.

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

OpenPGP_signature.asc
Description: OpenPGP digital signature