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.