Ergus <spacibba@aol.com> writes:

> What you do in the patch is basically the same that is in the branch,

IMO the key differece is that the patch doesn't do any calculation of
completions count based on line height, count of "\n" in separator etc.
I propose use the 'icomplete-prospects-height' value as the count of
completions that must be shown.

Let's see how the patch deals with mentioned user requests:

> multiple \n in the separator

(setq icomplete-hide-common-prefix nil)
(setq icomplete-separator "\n----------\n")
(setq icomplete-prospects-height 3)
(completing-read "prompt: " '("completion1" "completion2" "completion3"))

Doesn't matter how many \n is in the separator.  Just show 3
completions.
See multiple-n.png attached.

> using a different font size in the minibuffer

Still show 3 completions, some text may doesn't fit in case the font
size will be too big.

> display the completions in window-only frames like in mapple

Thats actually why the patch was implemented.  See,
maple-minibuffer-mode uses fixed frame height so the branch is show some
completions that fits based on frame-pixel-height.  But mini-frame-mode,
which I use, uses resizeable minibuffer-only frame to show the
minibuffer content and the branch doesn't show any completions.
I mention this issue earlier:
https://lists.gnu.org/archive/html/emacs-devel/2020-11/msg00124.html

In this usecase the patch behave better.

> having a first candidate longer than a single line/occupying multiple
> lines

Still show 3 completions, but minibuffer window may occupy more than 3
lines.
See long-completions.png attached.

Oh, link to mini-frame-mode if needed:
https://raw.githubusercontent.com/muffinmad/emacs-mini-frame/master/mini-frame.el