Re: Allowing completion sources to customize completion display

[Spencer Baugh]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Thu, 23 Nov 2023 13:20:27 -0800
>> Cc: sbaugh@janestreet.com, emacs-devel@gnu.org
>> From: Jim Porter <jporterbugs@gmail.com>
>> 
>> On 11/23/2023 12:47 AM, Eli Zaretskii wrote:
>> > IMNSHO, it will be a sad day when different completion sources will
>> > present different completion UI.  There will be no end to user
>> > confusion.
>> 
>> I think Spencer's suggestion below would be ok (assuming it actually 
>> works). Then it's up to the users themselves to opt-in to different UI 
>> for different sources:
>> 
>> On 11/22/2023 3:05 PM, Spencer Baugh wrote:
>> > - Maybe completion-category-overrides could change
>> >   completion-in-region-function based on the category?
>
> I don't see how this resolves the issue I had in mind, which is that
> users should NOT be presented with different completion-related
> displays and use different completion-related commands depending on
> the source of the completion data.  Quite the opposite: each source of
> the completion data should be able to adapt its presentation to the
> user preferences, as expressed via user options (if we have such
> UI-related options).  Users should not re-learn how to use completion
> in Emacs each time we add some new source of completion data to some
> command that offers completion.
>
> E.g., consider the following half-theoretical example: suppose the
> file-name completion learns to offer completion candidates from some
> source other than the list of files in default-directory -- my point
> is that those additional files that come from those other sources
> should be displayed in exactly the same way as the "traditional"
> source, and let users use the same commands to complete.  Anything
> else would be terribly confusing, and we should not do it.

Ah, yes, this cued me to think about it differently.  I think you're
right that I don't want to customize the UI based on the completion
source.

In my example, I was considering two sources, one which returns symbols
and one which usually returns big multi-line strings.  And I, as a user,
wanted the default Completions buffer for the first, and inline preview
for the second.

But basing this on the source is totally wrong.  Instead if I, as a
user, think inline preview is better for multi-line completion
candidates, then inline preview should be used for multi-line completion
candidates regardless of where those candidates come from.

So I, as a user, can just configure my completion UI to detect
multi-line completion candidates and alter the UI in that case.  No need
to care about the sources of completion candidates.

And such configuration options would be straightforward to add to any
completion UI, including the default completion-in-region-function.

So that seems great, and is obviously how it should work.

---------------

Now just separately speculating about what concrete options might be
nice to add at some point to the default completion UI, to get nice
inline preview behavior for multi-line strings...

Perhaps two options:

- completions-ghost-preview=t shows, in the buffer or minibuffer, a
  grayed-out "ghost" preview of the currently selected completion
  candidate.

- completions-multi-line-suppress=t makes the *Completions* buffer
  shrink down to just show completion-header-format and
  completion-show-help whenever there's multi-line candidates among the
  completions.  (So you'd only have the preview from
  completions-ghost-preview.)