Allowing completion sources to customize completion display

Allowing completion sources to customize completion display

[Spencer Baugh]

If I have multiple sources for completion active at once, I might prefer
different completion sources to be displayed differently.

For example, if a completion source returns individual symbols,
displaying the symbols in the *Completions* buffer seems good.
So the default completion-in-region-function is good.

But if a completion source returns multi-line blocks of text, I might
want to see those blocks of text displayed in context in the buffer,
rather than in a separate buffer.  Perhaps I'd see only the first
completion candidate displayed in-buffer, and have some key bindings
which let me cycle between them.  The exact details of the UI aren't
important, just that it's different from what I want for symbol
completion.  So I'd set completion-in-region-function to something
different.

I have completion-at-point-functions='(symbol-completion
block-completion), so if symbol-completion returns nil then I get
block-completion instead - exactly what I want.

But the same completion-in-region-function and UI has to be used
regardless of whether I'm getting symbol-completion or block-completion
- I don't see a way to change completion-in-region-function based on the
source.

Maybe we should add one?

Some possibilities:
- Maybe completion table metadata could just include a
  completion-in-region-function to use?

- Maybe completion-category-overrides could change
  completion-in-region-function based on the category?

- Maybe something else entirely?

Re: Allowing completion sources to customize completion display

[Eshel Yaron]

Spencer Baugh <sbaugh@janestreet.com> writes:

> If I have multiple sources for completion active at once, I might prefer
> different completion sources to be displayed differently.
>
> ...
>
> But the same completion-in-region-function and UI has to be used
> regardless of whether I'm getting symbol-completion or block-completion
> - I don't see a way to change completion-in-region-function based on the
> source.
>
> Maybe we should add one?

FWIW I had similar thoughts just the other day.  Allowing capfs to
request a certain selection UI makes sense in some situations, because
sometimes the most appropriate UI may depend on the results of a
specific capf.  For example, say we have a legacy completion command,
e.g. `ispell-complete-word`, that we want to port to a capf.  But the
legacy completion command comes with its bespoke completion selection
UI, so it might be desirable to have the new capf mimic the legacy UI
during the transition phase, without affecting other capfs, so other
capfs still use the regular UI when they take effect.

OTOH, IMO it's better to keep the UI as consistent and predictable as
possible, so I would avoid using such a capability too liberally.

> Some possibilities:
> - Maybe completion table metadata could just include a
>   completion-in-region-function to use?
>
> - Maybe completion-category-overrides could change
>   completion-in-region-function based on the category?
>
> - Maybe something else entirely?

How about something like the following?  That seems simple enough and
gives individual capfs full discretion to specify their selection UI.

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 5c12d9fc914..ff5472040d3 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -2823,7 +2823,10 @@ completion-at-point
                (lambda ()
                  ;; We're still in the same completion field.
                  (let ((newstart (car-safe (funcall hookfun))))
-                   (and newstart (= newstart start))))))
+                   (and newstart (= newstart start)))))
+              (completion-in-region-function
+               (or (plist-get plist :completion-in-region-function)
+                   completion-in-region-function)))
          (completion-in-region start end collection
                                (plist-get plist :predicate))))
       ;; Maybe completion already happened and the function returned t.

Re: Allowing completion sources to customize completion display

[Eli Zaretskii]

> From: Eshel Yaron <me@eshelyaron.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 23 Nov 2023 09:25:19 +0100
> 
> How about something like the following?  That seems simple enough and
> gives individual capfs full discretion to specify their selection UI.

IMNSHO, it will be a sad day when different completion sources will
present different completion UI.  There will be no end to user
confusion.

Completion UI is a user preference, and if we want to support
different UIs (as we already do), we should leave it to the user to
specify the UI he/she prefers, and then abide by that.
Completion-related frameworks that cannot work like that should not
pretend being "completion", but some different features, even if they
use completion functions under the hood.

Re: Allowing completion sources to customize completion display

[sbaugh]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: Eshel Yaron <me@eshelyaron.com>
>> Cc: emacs-devel@gnu.org
>> Date: Thu, 23 Nov 2023 09:25:19 +0100
>> 
>> How about something like the following?  That seems simple enough and
>> gives individual capfs full discretion to specify their selection UI.
>
> IMNSHO, it will be a sad day when different completion sources will
> present different completion UI.  There will be no end to user
> confusion.
>
> Completion UI is a user preference, and if we want to support
> different UIs (as we already do), we should leave it to the user to
> specify the UI he/she prefers, and then abide by that.

Sure.  I, as a user, want to specify two different UIs for two different
completion sources.

Currently this is impossible.

Re: Allowing completion sources to customize completion display

[Eli Zaretskii]

> From: sbaugh@catern.com
> Date: Thu, 23 Nov 2023 12:38:22 +0000 (UTC)
> Cc: Eshel Yaron <me@eshelyaron.com>, sbaugh@janestreet.com,
> 	emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> >
> > IMNSHO, it will be a sad day when different completion sources will
> > present different completion UI.  There will be no end to user
> > confusion.
> >
> > Completion UI is a user preference, and if we want to support
> > different UIs (as we already do), we should leave it to the user to
> > specify the UI he/she prefers, and then abide by that.
> 
> Sure.  I, as a user, want to specify two different UIs for two different
> completion sources.
> 
> Currently this is impossible.

It shouldn't be possible.  Users should not need to be aware of the
completion sources.

Re: Allowing completion sources to customize completion display

[sbaugh]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: sbaugh@catern.com
>> Date: Thu, 23 Nov 2023 12:38:22 +0000 (UTC)
>> Cc: Eshel Yaron <me@eshelyaron.com>, sbaugh@janestreet.com,
>> 	emacs-devel@gnu.org
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> >
>> > IMNSHO, it will be a sad day when different completion sources will
>> > present different completion UI.  There will be no end to user
>> > confusion.
>> >
>> > Completion UI is a user preference, and if we want to support
>> > different UIs (as we already do), we should leave it to the user to
>> > specify the UI he/she prefers, and then abide by that.
>> 
>> Sure.  I, as a user, want to specify two different UIs for two different
>> completion sources.
>> 
>> Currently this is impossible.
>
> It shouldn't be possible.  Users should not need to be aware of the
> completion sources.

Why not?  I just explained a use case where users are definitely already
aware of the completion sources, and Eshel mentioned another one.

Re: Allowing completion sources to customize completion display

[Eli Zaretskii]

> From: sbaugh@catern.com
> Date: Thu, 23 Nov 2023 14:03:37 +0000 (UTC)
> Cc: me@eshelyaron.com, sbaugh@janestreet.com, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> >> From: sbaugh@catern.com
> >> Date: Thu, 23 Nov 2023 12:38:22 +0000 (UTC)
> >> Cc: Eshel Yaron <me@eshelyaron.com>, sbaugh@janestreet.com,
> >> 	emacs-devel@gnu.org
> >> 
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >> >
> >> > IMNSHO, it will be a sad day when different completion sources will
> >> > present different completion UI.  There will be no end to user
> >> > confusion.
> >> >
> >> > Completion UI is a user preference, and if we want to support
> >> > different UIs (as we already do), we should leave it to the user to
> >> > specify the UI he/she prefers, and then abide by that.
> >> 
> >> Sure.  I, as a user, want to specify two different UIs for two different
> >> completion sources.
> >> 
> >> Currently this is impossible.
> >
> > It shouldn't be possible.  Users should not need to be aware of the
> > completion sources.
> 
> Why not?  I just explained a use case where users are definitely already
> aware of the completion sources, and Eshel mentioned another one.

You _can_ be aware of the source, but we must not _require_ users to
be aware.  If the user is NOT aware, he/she will not be able to set up
the UI according to the source.

Re: Allowing completion sources to customize completion display

[Dmitry Gutov]

On 23/11/2023 01:05, Spencer Baugh wrote:
> But the same completion-in-region-function and UI has to be used
> regardless of whether I'm getting symbol-completion or block-completion
> - I don't see a way to change completion-in-region-function based on the
> source.

completion-in-region-function accepts COLLECTION, right? That's usually 
the completion table. From there, you can access the table's metadata 
and see its category or etc (if you control the table, it could contain 
some additional distinctions).

So your custom completion-in-region-function could look up metadata and 
dispatch to one of the two specific interfaces, couldn't it?

Re: Allowing completion sources to customize completion display

[Jim Porter]

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?

Whether that's the best solution is another story, but I don't think it 
would cause any extra confusion, since nothing would change by default.

Re: Allowing completion sources to customize completion display

[Eli Zaretskii]

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

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

RE: [External] : Re: Allowing completion sources to customize completion display

[Drew Adams]

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

FWIW (I'm not following this thread) -

Icicles has option `icicle-hide-non-matching-lines-flag',
which you can toggle anytime during completion with
`C-u C-x .':

  Non-nil means hide candidate lines that do not match input.
  This applies only to multi-line candidates in buffer
  `*Completions*'.  Lines that do not contain text matched
  by your current minibuffer input are elided using ellipsis
  (`...').

Also option `icicle-hide-common-match-in-Completions-flag',
which you can toggle during completion with just `C-x .':

  Non-nil means hide the common match for your input, in
  `*Completions*'.  The common match used here is governed
  by option `icicle-expand-input-to-common-match'.  It is
  elided using ellipsis (`...').

When you hide non-matching lines of completions or their
common-match portions you still see all of the candidates.
It's just that some of their text may be elided.

Hiding common-match text can be especially useful when
that portion of the candidates is large, as it often is
with absolute file names having a common subdirectory.

This is _not_ specific to any particular kind or category
of completion.  It's a question of what a particular user
finds most useful at any given time.  Do _you_ want to
hide some candidate details right _now_, or not?

As usual, my advice for this kind of thing is to give
users control - don't just deciding on a "DWIM" behavior
(which might be fine as a _default_ behavior but should
not be the only one).  Let _users_ decide what "I mean"
means at any given time in any given context.

A user option sets a user's preferred default behavior.
But it's even more important to be able to control the
behavior dynamically, by toggling or cycling among
possible behaviors.

It's good (imperative, really) to give users dynamic
control.  But it can also help to give them (and library
writers) control over the default behavior of a _given
command_.  For hiding the common match among the current
completions this is done by adding/removing property
`icicle-hide-common-match' to/from a command symbol that
uses completion.

For example, by default command `icicle-locate-file' has
(put 'icicle-locate-file 'icicle-hide-common-match t).
But someone who wants that command to show common matches
by default can put this it their init file:
(put 'icicle-locate-file 'icicle-hide-common-match nil)

HTH.

Re: Allowing completion sources to customize completion display

[Dmitry Gutov]

On 24/11/2023 19:28, Spencer Baugh wrote:
> 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.

Are multi-line completions better shown inline? If I had to choose, I 
might actually choose the opposite: show the shorter ones inline, and 
the long ones in a separate buffer -- so that the current buffer's text 
doesn't jump up and down as I'm typing something.

But that strongly depends on how those long completions are going to be 
presented, whether they should replace the current text or just add new 
one (multiple lines of it), whether they are allowed to vary a lot, etc.

Re: Allowing completion sources to customize completion display

[Eli Zaretskii]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Cc: Jim Porter <jporterbugs@gmail.com>,  me@eshelyaron.com,
>  emacs-devel@gnu.org, Dmitry Gutov <dmitry@gutov.dev>, Juri Linkov
>  <juri@linkov.net>
> Date: Fri, 24 Nov 2023 12:28:34 -0500
> 
> 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.

I'm not sure I understand what you mean by "multi-line completion
candidates", but if I do, IMO we should display each supported format
of completion candidates in a way that fits that format.  IOW, there's
no reason to ask the user to configure that; we should instead provide
OOTB built-in UI for displaying candidates based on their "type".

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

If this is about preview of candidates specifically, using the
*Completions* buffer doesn't sound like a good idea to me, since
popping a buffer up and down and resizing its window as the user types
produces annoying visual effects, and also will slow down the preview,
since these operations are relatively expensive.

How about showing a multiline "ghost" instead?  Or maybe you should
produce a few examples of such multiline candidates, so that this
discussion is less academic?

Re: Allowing completion sources to customize completion display

[sbaugh]

Dmitry Gutov <dmitry@gutov.dev> writes:
> On 24/11/2023 19:28, Spencer Baugh wrote:
>> 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.
>
> Are multi-line completions better shown inline? If I had to choose, I
> might actually choose the opposite: show the shorter ones inline, and
> the long ones in a separate buffer -- so that the current buffer's
> text doesn't jump up and down as I'm typing something.

The idea is that multi-line completions are big, so you can only really
afford to show one large completion candidate on-screen at a time.
Whereas for shorter completions you can usefully fit multiple on screen
at a time.

To be clear, I haven't mentioned any in-buffer menus like company-mode
has.  If it was done with company certainly there would be in-buffer
menus, and I think what I would want is "always show a preview frontend,
and show a tooltip frontend only if the completion candidates are
small. (not multi-line)".

> But that strongly depends on how those long completions are going to
> be presented, whether they should replace the current text or just add
> new one (multiple lines of it), whether they are allowed to vary a
> lot, etc.

The long completions in my case are ones which can both modify or add
text, both before or after point.

But that's an interesting point.  An in-buffer menu (like company-mode
has) is a lot less suitable for completions which modify the text in
complex ways.  With such completions, an in-buffer preview is nicer.

So perhaps that's another way a completion UI (such as company) could
alter its behavior based on the completions: only show completion
candidates in an in-buffer menu (a tooltip frontend) if they are
"simple" (e.g. just symbol completion which leaves point after the newly
inserted symbol).  If they are complex, do an in-buffer preview.

Re: Allowing completion sources to customize completion display

[Dmitry Gutov]

On 25/11/2023 19:36, sbaugh@catern.com wrote:
> Dmitry Gutov <dmitry@gutov.dev> writes:
>> On 24/11/2023 19:28, Spencer Baugh wrote:
>>> 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.
>>
>> Are multi-line completions better shown inline? If I had to choose, I
>> might actually choose the opposite: show the shorter ones inline, and
>> the long ones in a separate buffer -- so that the current buffer's
>> text doesn't jump up and down as I'm typing something.
> 
> The idea is that multi-line completions are big, so you can only really
> afford to show one large completion candidate on-screen at a time.
> Whereas for shorter completions you can usefully fit multiple on screen
> at a time.
> 
> To be clear, I haven't mentioned any in-buffer menus like company-mode
> has.  If it was done with company certainly there would be in-buffer
> menus, and I think what I would want is "always show a preview frontend,
> and show a tooltip frontend only if the completion candidates are
> small. (not multi-line)".

I hadn't considered company-mode in that context, but the preview 
frontend in there should look more or less like the "Completion Preview" 
feature proposed (or recently added?) to the core.

>> But that strongly depends on how those long completions are going to
>> be presented, whether they should replace the current text or just add
>> new one (multiple lines of it), whether they are allowed to vary a
>> lot, etc.
> 
> The long completions in my case are ones which can both modify or add
> text, both before or after point.
> 
> But that's an interesting point.  An in-buffer menu (like company-mode
> has) is a lot less suitable for completions which modify the text in
> complex ways.  With such completions, an in-buffer preview is nicer.
> 
> So perhaps that's another way a completion UI (such as company) could
> alter its behavior based on the completions: only show completion
> candidates in an in-buffer menu (a tooltip frontend) if they are
> "simple" (e.g. just symbol completion which leaves point after the newly
> inserted symbol).  If they are complex, do an in-buffer preview.

The menu can still be shown if the long candidates are "smartly" 
truncated in some way. And yeah, for that usage the preview frontend 
should probably be always-on, not just when there is just one completion.

Re: Allowing completion sources to customize completion display

[Eli Zaretskii]

> Date: Sat, 25 Nov 2023 20:27:51 +0200
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> I hadn't considered company-mode in that context, but the preview 
> frontend in there should look more or less like the "Completion Preview" 
> feature proposed (or recently added?) to the core.

It is possible that providing an in-buffer preview for multi-line
completions makes no sense, and we shouldn't even try.  If the
solutions are to show the preview in a separate window, then how is
this different from popping up the *Completions* buffer?

Re: Allowing completion sources to customize completion display

[Dmitry Gutov]

On 25/11/2023 21:07, Eli Zaretskii wrote:
>> Date: Sat, 25 Nov 2023 20:27:51 +0200
>> From: Dmitry Gutov<dmitry@gutov.dev>
>>
>> I hadn't considered company-mode in that context, but the preview
>> frontend in there should look more or less like the "Completion Preview"
>> feature proposed (or recently added?) to the core.
> It is possible that providing an in-buffer preview for multi-line
> completions makes no sense, and we shouldn't even try.  If the
> solutions are to show the preview in a separate window, then how is
> this different from popping up the*Completions*  buffer?

I think when we say "preview", we usually mean "inline preview". Not 
separate window.

Re: Allowing completion sources to customize completion display

[Eli Zaretskii]

> Date: Sat, 25 Nov 2023 21:08:20 +0200
> Cc: sbaugh@catern.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 25/11/2023 21:07, Eli Zaretskii wrote:
> >> Date: Sat, 25 Nov 2023 20:27:51 +0200
> >> From: Dmitry Gutov<dmitry@gutov.dev>
> >>
> >> I hadn't considered company-mode in that context, but the preview
> >> frontend in there should look more or less like the "Completion Preview"
> >> feature proposed (or recently added?) to the core.
> > It is possible that providing an in-buffer preview for multi-line
> > completions makes no sense, and we shouldn't even try.  If the
> > solutions are to show the preview in a separate window, then how is
> > this different from popping up the*Completions*  buffer?
> 
> I think when we say "preview", we usually mean "inline preview". Not 
> separate window.

AFAIR, one of the proposals for handling the preview of multi-line
candidates was to show a special buffer (supposedly, in a window, how
else?).