bug#71716: [PATCH] Add new completion-preview-insert-{word, sexp} commands

[Eshel Yaron]

Hi Jules,

Jules Tamagnan <jtamagnan@gmail.com> writes:

> Tags: patch

Thanks for the feature request and for the patch.

> * Problem
>
> Oftentimes when completing a value a user wants a small part of a
> completion but not the entire thing. This happens frequently when
> iterating on shell commands or on similar lines of
> code. completion-preview can help with this by quickly suggesting a
> sensible completion pulled from any completion-at-point function. The
> problem is that accepting a full completion is often inefficient because
> one might only want the first part of that completion. This leads to a
> lot of deletions after the fact.
>
> * Solution
>
> Allow inserting of partial completions when using
> completion-preview.

We currently have completion-preview-complete (M-i) for that: it inserts
the common part (prefix) of all completion candidates.

> For this I've added two new commands completion-preview-insert-word
> and completion-preview-insert-sexp which will insert the next word or
> sexp in the completion.

That sounds interesting.  The ELPA package capf-autosuggest.el provided
a similar feature, IIRC.  I'd like to get a better understanding of the
use case though: when would you use one of these commands instead of
completion-preview-complete?

> For consistency with completion-preview-insert I've refactored the
> code so that these three commands share a common code path.

Good idea, but there are two issues with the current implementation:

1. AFAICT, unlike completion-preview-insert, these new commands should
   preserve (the rest of) the completion preview.  So instead of
   dismissing the preview by disabling completion-preview-active-mode
   and then relying on the subsequent post-command-hook to recreate the
   preview, I think these commands should modify (e.g. remove a word
   from the start of) the after-string property of the preview overlay,
   and inhibit a subsequent update of the preview, like we do in
   completion-preview-complete.  That way we avoid recomputing the
   completion candidates, which may lead to a flicker in this case.

2. The temporary buffer where the motion command is executed has a
   different major mode than the original buffer, so they might have
   different notions of words/sexps.

> * Notes
>
>  - I've added new tests for this and ensured that previous ones continue
>    to pass.   
>  - I've signed the copyright assignments and have contributed to emacs
>    previously.

That's great, thanks.


Eshel