From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#11035: 24.0.94; icomplete with multiline candidates and standalone minibuffer Date: Sat, 17 Mar 2012 08:08:27 -0700 Message-ID: <24D5DCA1F5CC4998B913A2618831F2BB@us.oracle.com> References: <56626A33CFEC4F62B686BEBB6D722F6C@us.oracle.com> <83pqcb2xtr.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1331996999 5099 80.91.229.3 (17 Mar 2012 15:09:59 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 17 Mar 2012 15:09:59 +0000 (UTC) Cc: 11035@debbugs.gnu.org To: "'Eli Zaretskii'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Mar 17 16:09:56 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1S8vGP-0003Wn-T6 for geb-bug-gnu-emacs@m.gmane.org; Sat, 17 Mar 2012 16:09:50 +0100 Original-Received: from localhost ([::1]:44517 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8vGP-0007cl-5C for geb-bug-gnu-emacs@m.gmane.org; Sat, 17 Mar 2012 11:09:49 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:56854) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8vGL-0007YK-P5 for bug-gnu-emacs@gnu.org; Sat, 17 Mar 2012 11:09:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S8vGJ-0008E0-OJ for bug-gnu-emacs@gnu.org; Sat, 17 Mar 2012 11:09:45 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:47965) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8vGJ-0008Dp-KY for bug-gnu-emacs@gnu.org; Sat, 17 Mar 2012 11:09:43 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1S8vje-0007xN-PB for bug-gnu-emacs@gnu.org; Sat, 17 Mar 2012 11:40:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 17 Mar 2012 15:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11035 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 11035-submit@debbugs.gnu.org id=B11035.133199875130515 (code B ref 11035); Sat, 17 Mar 2012 15:40:02 +0000 Original-Received: (at 11035) by debbugs.gnu.org; 17 Mar 2012 15:39:11 +0000 Original-Received: from localhost ([127.0.0.1]:54796 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S8vio-0007w7-6s for submit@debbugs.gnu.org; Sat, 17 Mar 2012 11:39:10 -0400 Original-Received: from acsinet15.oracle.com ([141.146.126.227]:44593) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S8viZ-0007vJ-2Q for 11035@debbugs.gnu.org; Sat, 17 Mar 2012 11:39:06 -0400 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q2HF8XOB027925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 17 Mar 2012 15:08:34 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q2HF8W4l027702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 Mar 2012 15:08:33 GMT Original-Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q2HF8Wg3008536; Sat, 17 Mar 2012 10:08:32 -0500 Original-Received: from dradamslap1 (/10.159.43.228) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 17 Mar 2012 08:08:32 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83pqcb2xtr.fsf@gnu.org> Thread-Index: Ac0EPQ/oqoQv0G+fTiC9bacWc943EAADVXZw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-CT-RefId: str=0001.0A090201.4F64A8F2.008D,ss=1,re=0.000,fgs=0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:57855 Archived-At: > > 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.