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.