Re: on helm substantial differences

[Jean Louis]

* Juri Linkov <juri@linkov.net> [2020-11-17 22:33]:
> > Before knowing what's the best approach, I think we should clearly
> > decide what would be the "ideal" new API.  E.g. should it return "any
> > string" and then it'd be up to the infrastructure code to store
> > side-info about what is the corresponding candidate's actual text?
> 
> After trying different variants, it turned out that the most convenient
> is to use annotation-function that can contain a placeholder for the
> completion candidate.  Currently "%s" is used as a placeholder,
> for example, "prefix %s suffix" but it can be any string.
> Or maybe better to allow returning a list of two separate strings
> for prefix and suffix from annotation-function?

If I may comment on (not related to above paragraph) the attached .png
picture is that minibuffer enlarged very much over the screen. What
would happen if the screen would be split in two windows before
completion, would then the very narrow scratch buffer on top be
divided with another mode line? In that case both divided windows
would be very narrow and not readable. Sometimes at least the focused
window should be readable during completion as completion is very
general for programmers who may need reference in the window they are
working in.

Large minibuffer window practically splits window in 2 parts, one very
narrow, minibuffer very high. In this case your *scratch* buffer,
would it have more text, would not be usable at all as it little would
be visible.

My suggestion is that minibuffer rather makes proper split window by
default or that it does not enlarge over the screen more then
the calculated half of the full window, as that way user would have
visible buffer.

My suggestion for Emacs that already has 2 split windows is that
minibuffer completion does not resize the focused window as that is
where user works and expects (probably) to maybe insert something into
that buffer or use it as reference during completion. Rather
minibuffer should use the unfocused other window (from two or more
split windows) to show its completions then enlarging itself over the
screen and effectively disturbing the visual static interface.