unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Drew Adams <drew.adams@oracle.com>
Cc: 11035@debbugs.gnu.org
Subject: bug#11035: 24.0.94; icomplete with multiline candidates and standalone minibuffer
Date: Sat, 17 Mar 2012 14:53:20 +0200	[thread overview]
Message-ID: <83pqcb2xtr.fsf@gnu.org> (raw)
In-Reply-To: <56626A33CFEC4F62B686BEBB6D722F6C@us.oracle.com>

> 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.





  reply	other threads:[~2012-03-17 12:53 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-17  0:10 bug#11035: 24.0.94; icomplete with multiline candidates and standalone minibuffer Drew Adams
2012-03-17 12:53 ` Eli Zaretskii [this message]
2012-03-17 14:57   ` Eli Zaretskii
2012-03-17 15:08     ` Drew Adams
2012-03-17 18:17       ` Eli Zaretskii
2012-03-18  1:14     ` Stefan Monnier
2012-03-18  1:49       ` Drew Adams
2012-03-18 16:59       ` Eli Zaretskii
2012-03-17 15:08   ` Drew Adams
2012-03-17 18:30     ` Eli Zaretskii
2012-03-17 20:13       ` Drew Adams
2012-03-17 20:47         ` Eli Zaretskii
2012-03-17 21:43           ` Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83pqcb2xtr.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=11035@debbugs.gnu.org \
    --cc=drew.adams@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).