Re: [PATCH] Support "\n" in icomplete-separator

[Ergus <spacibba@aol.com>]

On Fri, Nov 06, 2020 at 02:36:14PM +0200, Andrii Kolomoiets wrote:
>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:
>
Yes, I understand that; actually the height calculation was made because
of this:

```
(setq icomplete-show-matches-on-no-input t)
(icomplete-mode 1)
(setq icomplete-separator "\n")

(defface vmacs-minibuffer-font
  `((t :inherit default :height 1.3))
  "The default font for minibuffer buffer.
Monospaced font whihc is fixed idth and height is recommended."
  :group 'minibuffer)

(defun vmacs-minibuffer-hook()
  (set (make-local-variable 'buffer-face-mode-face) 'vmacs-minibuffer-font)
  (buffer-face-mode t))

(add-hook 'minibuffer-setup-hook #'vmacs-minibuffer-hook)

(setq max-mini-window-height 10)   ;; add  this line
```
in here: https://lists.gnu.org/archive/html/emacs-devel/2020-09/msg01578.html

Up to some months ago the pixel calculation was required because showing
more candidates than fit in the minibuffer hided the prompt. There were
long discussions related with that.

Up to now there is a fix in the display engine, but I don't really know
if we could totally ignore the max-height with that. Probably we could
relax it a bit, but not totally.

>> 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.
>
This of course is supposed to work. But try with more candidates like 10
or so. In the branch I basically take the min between the
icomplete-prospects-height and the number of candidates that fit in
max-mini-window-height.

>> 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.
>
I think that with the Eli fix probably we could relax at least this part
a bit. 

>> 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.
>
I can't reproduce the issue, that's why I didn't reply; sorry. In your
use case I suppose it works "better" because the patch totally ignores
the window height to fit; which, as I mention before, I am not sure is
something we can do in the general case due to the prompt issue.

If the prompt issue is totally away, we could; but I will need some
confirmation from Eli or Stefan; but last time I tried it was still
there.

In any case if in your case it is broken, then we probably need another
considerations.

>> 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
>
Best,
Ergus