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

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

[Drew Adams]

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).
 
If you use the mouse to click the title bar of another frame at this
point, selecting it, you can see that the minibuffer now shows the first
line instead:
 
This is the prompt: b
 
with the cursor after the `b'.  Why this change in display, I don't know.
 
If you click the mouse on the minibuffer frame title bar, the display
returns to showing (bbbb candidate etc., with the cursor shown at bol.
 
(In my own setup, I see the same problem even without the final \n at
the end of each completion candidate, but the recipe above is the
simplest I can offer to repro the problem.)
 
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).
 
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).
 
Since the overlay is not really buffer content, it doesn't get measured,
so the frame is not refit to accommodate the text of the overlay.  This
is why the last line shown for Emacs 22.3 above does not appear in the
frame in Emacs 23+ at all.
 
This is a drawback, IMO, with using an overlay for icomplete: the
overlay is not "in" the minibuffer, so operations on the minibuffer
content do not take it into account.  (That is of course also the
strength of using an overlay: it is not part of the minibuffer content.)
 
Perhaps Emacs Dev has a similar problem for icomplete wrt resizing the
minibuffer window when it is not standalone - dunno.  If someone has a
suggestion in this regard, I'm interested.
 
In sum, my code works fine in Emacs 20-22, but is broken in Emacs 23 and
later because of the changed implementation of icomplete.
 

In GNU Emacs 24.0.94.1 (i386-mingw-nt5.1.2600)
 of 2012-02-26 on MARVIN
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.6) --no-opt --enable-checking --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include'
 

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.

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

[Eli Zaretskii]

> Date: Sat, 17 Mar 2012 14:53:20 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 11035@debbugs.gnu.org
> 
> > 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.

If what we want is to display the cursor on the left parenthesis after
"b" in the first line (which is what we already do when the candidates
don't include newlines), then the following patch will achieve that.

As this isn't a regression wrt Emacs 23, Stefan and Chong, please tell
if this should be installed or deferred till after 24.1.

=== modified file 'src/xdisp.c'
--- src/xdisp.c	2012-03-02 15:40:44 +0000
+++ src/xdisp.c	2012-03-17 14:32:13 +0000
@@ -18456,9 +18456,11 @@ cursor_row_p (struct glyph_row *row)
       /* Suppose the row ends on a string.
 	 Unless the row is continued, that means it ends on a newline
 	 in the string.  If it's anything other than a display string
-	 (e.g. a before-string from an overlay), we don't want the
+	 (e.g., a before-string from an overlay), we don't want the
 	 cursor there.  (This heuristic seems to give the optimal
-	 behavior for the various types of multi-line strings.)  */
+	 behavior for the various types of multi-line strings.)
+	 One exception: if the string has `cursor' property on one of
+	 its characters, we _do_ want the cursor there.  */
       if (CHARPOS (row->end.string_pos) >= 0)
 	{
 	  if (row->continued_p)
@@ -18480,6 +18482,25 @@ cursor_row_p (struct glyph_row *row)
 		    result =
 		      (!NILP (prop)
 		       && display_prop_string_p (prop, glyph->object));
+		    /* If there's a `cursor' property on one of the
+		       string's characters, this row is a cursor row,
+		       even though this is not a display string.  */
+		    if (!result)
+		      {
+			Lisp_Object s = glyph->object;
+
+			for ( ; glyph >= beg && EQ (glyph->object, s); --glyph)
+			  {
+			    EMACS_INT gpos = glyph->charpos;
+
+			    if (!NILP (Fget_char_property (make_number (gpos),
+							   Qcursor, s)))
+			      {
+				result = 1;
+				break;
+			      }
+			  }
+		      }
 		    break;
 		  }
 	    }

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

[Drew Adams]

> If what we want is to display the cursor on the left parenthesis after
> "b" in the first line (which is what we already do when the candidates
> don't include newlines), then the following patch will achieve that.

Thanks for the quick patch, Eli.  I cannot try it now, since it means building
Emacs, but if it does what you describe then perhaps the first problem I
reported can be closed out.

If so, that would be great.  I've been hassling with this for a long time (since
Emacs 23) - it took me a while to see where the problem was.

If so, if you prefer then we could close this bug and I would open another one
for the buffer-fitting problem (with overlays etc.).  Alternatively, we could
leave that here and just leave this bug open for that part.  Let me know.

As soon as I can get a Windows build I'll let you know about your fix for the
line-display/cursor problem.  Thx.

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <11035@debbugs.gnu.org>
> Date: Sat, 17 Mar 2012 08:08:25 -0700
> 
> If so, if you prefer then we could close this bug and I would open another one
> for the buffer-fitting problem (with overlays etc.).  Alternatively, we could
> leave that here and just leave this bug open for that part.  Let me know.

I'd prefer a separate bug report, especially since its scope is not
yet clear and should be discussed.

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

[Stefan Monnier]

> As this isn't a regression wrt Emacs 23, Stefan and Chong, please tell
> if this should be installed or deferred till after 24.1.

It looks like a good fix, please install.


        Stefan

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

[Drew Adams]

> > As this isn't a regression wrt Emacs 23, Stefan and Chong, 
> > please tell if this should be installed or deferred till
> > after 24.1.
> 
> It looks like a good fix, please install.

Thx.

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Chong Yidong <cyd@stupidchicken.com>,  drew.adams@oracle.com,  11035@debbugs.gnu.org
> Date: Sat, 17 Mar 2012 21:14:50 -0400
> 
> > As this isn't a regression wrt Emacs 23, Stefan and Chong, please tell
> > if this should be installed or deferred till after 24.1.
> 
> It looks like a good fix, please install.

Done (revision 107628 on the trunk).

I'm closing the bug; if some leftovers are found, please reopen with
the details.

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

[Drew Adams]

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

Let's not let the ideal become the enemy of the good.

"In general" can mean handling all possible cases or it can mean handling most
of the cases or all or most of the common cases.  When you add the qualification
you added you are, I think, including more cases than I for this bug report.

My frame-fitting code does not try to handle mixed font sizes, proportional
text, etc. specially.  I'm not now looking for a solution that does more in this
regard than does my frame-fitting code.  That code works very well with
"ordinary", i.e., most common Emacs buffers.  In practice (in my experience)
this means 99.9% of buffers.  Even if it meant only 80% it would be great.  If
it meant only 50% it would still be very useful.

But since my frame-fitting code considers only text that is actually in the
buffer it obviously does not take overlays or other display artifacts into
account.  And that is the problem here (for the second problem mentioned in the
bug report).

> I'm quite sure we lack some infrastructure to make what you want
> possible to be done reliably.

If you think that what I want for this bug fix includes handling variable text
sizes etc. then that is incorrect.

But if you are only saying that there is no easy way to take into account the
overlay text then you might be right.  At any rate, my fitting code does not
currently deal with that.

Perhaps someone has a simple suggestion for handling that?  It would be great to
have a function that took the real buffer text and the current overlays
(and...?) and returned the "effective" buffer text, i.e., the buffer as
displayed.  And in such a way that I could then just use that effective
(displayed) text in the frame-fitting code.  That would be super.

It might be that doing that for some display effects is simpler than for others,
in which case just having a first approximation that handled, say, text
"inserted" by overlays, would be an improvement.  Then perhaps handling other
(all?) display artifacts (including text/overlay property `display') could be
added piecemeal as further enhancements.

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

I believe there is already a bug report asking for resizing etc. to take into
account all display behavior and artifacts.  No, I don't recall the bug number.
I do recall that Stefan agreed that it should be done, but I don't know whether
anyone has worked on it yet.

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

Yes, but I think it is more general than minibuffer or even frames.  Does
window-fitting to the buffer _as displayed_ work for this kind of thing (overlay
text, `display' property "inclusions", "deletions", "substitutions" etc.)?  I
don't know, but I doubt it.  I think that is what the other bug was about (whose
# I do not recall).

Or if window-fitting does already take care of this kind of thing, then please
point me to the code and I'll see if I can adapt it for frame-fitting.

There are two parts to this bug report.  I can separate them into separate bug
#s if you prefer.

1. The first is much more important to me in the immediate: get the
cursor/display problem fixed, so that users see something useful as in Emacs 22
and prior.

2. The second is about resizing based on the buffer as displayed: buffer text
plus overlay text.  I'm guessing that that is a harder problem, and anyway it is
less urgent for me.

Thx.

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <11035@debbugs.gnu.org>
> Date: Sat, 17 Mar 2012 08:08:27 -0700
> 
> My frame-fitting code does not try to handle mixed font sizes, proportional
> text, etc. specially.  I'm not now looking for a solution that does more in this
> regard than does my frame-fitting code.  That code works very well with
> "ordinary", i.e., most common Emacs buffers.  In practice (in my experience)
> this means 99.9% of buffers.  Even if it meant only 80% it would be great.  If
> it meant only 50% it would still be very useful.
> 
> But since my frame-fitting code considers only text that is actually in the
> buffer it obviously does not take overlays or other display artifacts into
> account.  And that is the problem here (for the second problem mentioned in the
> bug report).

If all you want to do is count display lines, I think you should be
able to do that by finding all the overlay and display strings in the
buffer or region you are interested in, and counting newlines in those
strings.  Also, newlines in buffer text that are covered by `display'
properties should not be counted.  Will that do what you want?  If so,
the next-overlay-change and next-single-char-property-change functions
are your friends.

> Perhaps someone has a simple suggestion for handling that?  It would be great to
> have a function that took the real buffer text and the current overlays
> (and...?) and returned the "effective" buffer text, i.e., the buffer as
> displayed.  And in such a way that I could then just use that effective
> (displayed) text in the frame-fitting code.  That would be super.

I think it's possible to write such a function, using the algorithm I
suggested above, but doing so would be somewhat overkill, as you are
not interested in the text to be displayed, just in the number of
lines in it.

> > I suggest to define the requirements for such a feature as a separate
> > feature-request bug report.
> 
> I believe there is already a bug report asking for resizing etc. to take into
> account all display behavior and artifacts.  No, I don't recall the bug number.
> I do recall that Stefan agreed that it should be done, but I don't know whether
> anyone has worked on it yet.

If you mean 10960, then it's about a different issue: the (pixel)
dimensions of the display margins, the area between the window edge
and the fringe.  By contrast, you are talking about the text area of
the display.

> > Or maybe we just need a resize-mini-frame option.
> 
> Yes, but I think it is more general than minibuffer or even frames.  Does
> window-fitting to the buffer _as displayed_ work for this kind of thing (overlay
> text, `display' property "inclusions", "deletions", "substitutions" etc.)?  I
> don't know, but I doubt it.  I think that is what the other bug was about (whose
> # I do not recall).

What is window-fitting?

I said resize-mini-frame, because only a minibuffer-only frame would
benefit from such automatic resizing.  Having general-purpose frames
expand and shrink according to the buffer size does not sound useful.
Maybe you meant special-purpose frames other than minibuffer frames.

> 2. The second is about resizing based on the buffer as displayed: buffer text
> plus overlay text.  I'm guessing that that is a harder problem, and anyway it is
> less urgent for me.

I think this second issue should be a separate bug report.

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

[Drew Adams]

> If all you want to do is count display lines,

No, except in this special case of minibuffer-frame fitting.  In the general
case the frame needs to be fit both horizontally and vertically.  The displayed
area ("text") is thus important.

> I think you should be
> able to do that by finding all the overlay and display strings in the
> buffer or region you are interested in, and counting newlines in those
> strings.  Also, newlines in buffer text that are covered by `display'
> properties should not be counted.  Will that do what you want?  If so,
> the next-overlay-change and next-single-char-property-change functions
> are your friends.

Perhaps, but I won't be tackling that anytime soon.  Instead, I've been looking
forward to the general solution discussed in the window-fitting case (a previous
bug report - see below.

> > Perhaps someone has a simple suggestion for handling that?

By that I meant something simpler than grabbing all overlays and text-properties
involved in displaying and working with them to come up with the text that is
displayed (as opposed to text actually in the buffer).  That's not trivial,
AFAICT.  But if it is, so much the better - I look forward to the bug fix.

> > It would be great to have a function that took the real buffer
> > text and the current overlays (and...?) and returned the
> > "effective" buffer text, i.e., the buffer as displayed.  And
> > in such a way that I could then just use that effective
> > (displayed) text in the frame-fitting code.  That would be super.
> 
> I think it's possible to write such a function, using the algorithm I
> suggested above,

That's essentially the previously reported bug, in essence.  So far, no one has
come up with such a function, AFAIK.

> but doing so would be somewhat overkill, as you are
> not interested in the text to be displayed, just in the number of
> lines in it.

In general I do need the actual displayed text (at least its dimensions), both
width and height.  It is only in the special case of a standalone minibuffer
that I need only the height, as mentioned above.

> > I believe there is already a bug report asking for resizing 
> > etc. to take into account all display behavior and artifacts.
> > No, I don't recall the bug number.  I do recall that Stefan
> > agreed that it should be done, but I don't know whether
> > anyone has worked on it yet.
> 
> If you mean 10960,

No, I do not.  The bug included a discussion with at least Stefan and me, and it
was much older than 10960.  See below.

> > > Or maybe we just need a resize-mini-frame option.
> > 
> > Yes, but I think it is more general than minibuffer or even 
> > frames.  Does window-fitting to the buffer _as displayed_
> > work for this kind of thing (overlay text, `display' property
> > "inclusions", "deletions", "substitutions" etc.)?  I
> > don't know, but I doubt it.  I think that is what the other 
> > bug was about (whose # I do not recall).
> 
> What is window-fitting?

`fit-window-to-buffer'.

> I said resize-mini-frame, because only a minibuffer-only frame would
> benefit from such automatic resizing.  Having general-purpose frames
> expand and shrink according to the buffer size does not sound useful.

Fitting a frame to its buffer text (or to whatever is displayed, when that
becomes a possibility) is extremely useful, IMHO.  Especially to someone who
uses non-nil `pop-up-frames' (or its equivalent) etc.

Imagine, if you use window-manager windows for other applications, if every such
window that was displayed had the same size, typically oversized for the
content: every little dialog box - everything.  That's what Emacs is like for
someone who uses frames by default, if s?he does not have automatic
frame-fitting.

> Maybe you meant special-purpose frames other than minibuffer frames.

No.

But my point about the question being more general than just the minibuffer and
more general than just frames had nothing to do with this.  The point is that it
applies to windows in general.

When you (or someone else) solve the buffer-as-displayed problem for
`fit-window-to-buffer' I imagine the same solution will be applicable to a
minibuffer window (and to a standalone minibuffer frame) and to frame-fitting in
general.

IOW, it's about determining the size of the buffer as displayed, and that will
be useful for lots of things, IMO.

> > 2. The second is about resizing based on the buffer as 
> > displayed: buffer text plus overlay text.  I'm guessing that
> > that is a harder problem, and anyway it is less urgent for me.
> 
> I think this second issue should be a separate bug report.

As I said, I recall that it was already reported (and discussed).  I did not
recall the bug number.  But I just searched for `fit-window-to-buffer' in the
bug-report database and came up with this, which I think is the one (bug #7822):
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7822.  And this is the emacs-devel
thread that led to it:
http://lists.gnu.org/archive/html/emacs-devel/2011-01/msg00323.html.

No one but Lennart paid any attention to that bug report, and Lennart was, IMO,
off-base.

But Stefan was involved in the emacs-devel discussion.  Please see that
discussion.  Stefan's conclusion seems to be that `fit-window-to-buffer' is
inadequate and broken, and that what I requested is not really an enhancement
request but a bug fix.  It just has not yet been fixed.

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <11035@debbugs.gnu.org>
> Date: Sat, 17 Mar 2012 13:13:36 -0700
> 
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7822.  And this is the emacs-devel
> thread that led to it:
> http://lists.gnu.org/archive/html/emacs-devel/2011-01/msg00323.html.
> 
> No one but Lennart paid any attention to that bug report, and Lennart was, IMO,
> off-base.
> 
> But Stefan was involved in the emacs-devel discussion.  Please see that
> discussion.  Stefan's conclusion seems to be that `fit-window-to-buffer' is
> inadequate and broken, and that what I requested is not really an enhancement
> request but a bug fix.  It just has not yet been fixed.

So why isn't count-screen-lines what you need?  If it doesn't work in
the specific case in point you need it, please show what is the use
case and how it fails in that use case.

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

[Drew Adams]

> So why isn't count-screen-lines what you need?

[Use of `count-screen-lines' has nothing to do with the text you quoted, BTW.
That (bug #7822 and associated emacs-devel discussion) is about having
`fit-window-to-buffer' take display artifacts into account.  And it is about
having a function that gives you both the width and height of the buffer as
displayed.]

But yes, I can use `count-screen-lines' to fix the resizing problem for the
minibuffer frame height (second part of this bug).  I wasn't aware of that
function.  And it's OK that it's not available for some older releases, because
in those releases icomplete does not use overlays.  Thank you for pointing out
`count-screen-lines'.

Without your C-source fix for the cursor placement, after fitting the frame
according to `count-screen-lines', the cursor ends up displayed at the end of
the overlay, which is worse than the behavior described in the bug report.  But
hopefully with your C fix we will be able to close this bug.  I will let you
know when I can get hold of a new Windows binary and see.

Thx.