Re: Inline completion preview

[chad <yandros@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1715 bytes --]

On Fri, Oct 27, 2023 at 3:34 PM Eshel Yaron <me@eshelyaron.com> wrote:

> [..]  For clarity, I'm attaching below a
> screenshot showing how such completion preview in an Elisp buffer.
>

I've seen a few systems try to add this sort of completion preview to
editing, and it seems to mostly be based on (ultra-common) mobile device
autocomplete UI. The problem with bringing that model into an editor is
that mobile device autocomplete is about helping users *append* text to the
*end* of a very small chunk of editable text. Those systems also have
various ways to "move the cursor", and they're uniformly considered worse,
because the interaction model is a bad fit for the user affordances.

I've seen a few systems that add this sort of in-line expansion suggestion
to actual text editors, where most of the editing happens in the middle,
not the end, and the jumpiness that results is, well, it's usually not
considered good. (The flashing/updating you get just from adapting the code
highlighting to such systems is jarring enough that most editors add extra
layers to mitigate it.) I don't know if it's accidental or intentional, but
I believe this sort of problem is why you almost always see examples
demonstrate mid-text suggestions via pop-ups, and in-line suggestions
nearly always demonstrated (as in this screenshot), at the end.

Put another way: there are strong reasons to consider Eli's suggestion that
Emacs grow/evolve infrastructure to display such suggestions using UI
methods beyond "just insert some specially-marked text", even if some users
will be happy to have the text quickly/easily plopped directly into the
buffer.

As usual, I hope this helps,
~Chad

[-- Attachment #2: Type: text/html, Size: 2165 bytes --]