GNU bug report logs - #11035
24.0.94; icomplete with multiline candidates and standalone minibuffer

Previous Next

Full log

View this message in rfc822 format

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: 11035 <at> debbugs.gnu.org
Subject: bug#11035: 24.0.94; icomplete with multiline candidates and standalone minibuffer
Date: Sat, 17 Mar 2012 08:08:27 -0700

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.