bug#11035: 24.0.94; icomplete with multiline candidates and standalone minibuffer

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Fri, 16 Mar 2012 17:10:04 -0700
> 
> 1. Download these two files from Emacs wiki:
> http://www.emacswiki.org/emacs/download/hexrgb.el
> http://www.emacswiki.org/emacs/download/oneonone.el
>  
> 2. Start Emacs like this:
> runemacs.exe -Q --debug-init -l "hexrgb.el" -l "oneonone.el" -f "1on1-emacs"
>  
> That gives you a standalone minibuffer frame that is two lines high.
>  
> 3. Turn on icomplete-mode.
>  
> 4. Evaluate this:
>  
> (completing-read
>  "This is the prompt: "
>  '(("aaaaa candidate\naaaaa second line\n")
>    ("bbbbb candidate\nbbbbb second line\n")
>    ("ccccc candidate\nccccc second line\n")
>    ("ddddd candidate\nddddd second line\n")
>    ("eeeee candidate\neeeee second line\n")
>    ("fffff candidate\nfffff second line\n")
>    ("ggggg candidate\nggggg second line\n")
>    ("hhhhh candidate\nhhhhh second line\n")))
>  
> 5. Type `b'.
>  
> Symptom: The minibuffer prompt and user input are moved up one line,
> out of the frame.  The cursor appears at bol, just before this
> icomplete overlay text:
>  
> (bbbb candidate
> bbbbb second line
>  
> The rest of the overlay text is off the bottom of the frame (that's
> normal, since it is only two lines high - but see below, near the end).

Here's a much simpler way of reproducing the problem, that doesn't
need any add-on packages:

  emacs -Q --eval "(add-to-list 'initial-frame-alist '(minibuffer . nil))"

  M-x icomplete-mode RET
  Type or copy/paste the above call to completing-read
  C-x C-e at the closing paren
  Type b

> This buggy behavior started with Emacs 23.  There is no such problem
> with Emacs 22.3 or prior.  In Emacs 23, the icomplete.el code switched
> from inserting text to using an overlay (which I agree should be a
> better approach, in principle, though I don't know if that change was
> just made gratuitously or was in response to some reported bug).
>  
> IOW, there is no problem in Emacs 22.3 or earlier.
>  
> In Emacs 22.3, the display appears like this:
>  
> This is the prompt: b(bbbb candidate
> bbbbb second line
> )  [Matched]
>  
> with the cursor on the left paren, after the first `b'.  That is normal
> (and useful).  The user can see the prompt and the input, in addition to
> the start of the first candidate (in fact all of the first candidate, in
> this case).

icomplete post-23 shows point at the end of the overlay.  This is a
consequence of using multi-line overlay strings: the cursor always
skips all but the last line of such a string.

So we need to decide whether we want to display the cursor on the left
paren instead, in this case.  Obviously, a 2-line minibuffer is not
large enough to display 3 lines it needs in this case, so some part of
the prompt will have to remain invisible whatever we decide.

> The other problem I have with the Emacs 23+ icomplete code is the
> following.  Although I recognize that using an overlay should make
> sense, it messes up my code, which automatically increases the
> minibufferframe height when the minibuffer content grows additional
> lines.  I do that using fit-frame.el (my library), which measures the
> buffer content to determine the needed frame height (respecting user-set
> limits).

You cannot do that in general, because the text may use various faces
whose size defeats any calculations based on line counts.  I'm quite
sure we lack some infrastructure to make what you want possible to be
done reliably.

I suggest to define the requirements for such a feature as a separate
feature-request bug report.

Or maybe we just need a resize-mini-frame option.