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.