From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 16 20:40:41 2012 Received: (at submit) by debbugs.gnu.org; 17 Mar 2012 00:40:41 +0000 Received: from localhost ([127.0.0.1]:54056 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S8hhI-0000xb-9H for submit@debbugs.gnu.org; Fri, 16 Mar 2012 20:40:41 -0400 Received: from eggs.gnu.org ([208.118.235.92]:53823) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S8hhE-0000xQ-9a for submit@debbugs.gnu.org; Fri, 16 Mar 2012 20:40:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S8hDu-0000K4-2X for submit@debbugs.gnu.org; Fri, 16 Mar 2012 20:10:19 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:48190) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8hDt-0000K0-UT for submit@debbugs.gnu.org; Fri, 16 Mar 2012 20:10:17 -0400 Received: from eggs.gnu.org ([208.118.235.92]:47050) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8hDr-00026p-Qo for bug-gnu-emacs@gnu.org; Fri, 16 Mar 2012 20:10:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S8hDp-0000Jn-DR for bug-gnu-emacs@gnu.org; Fri, 16 Mar 2012 20:10:15 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:42937) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8hDp-0000JU-67 for bug-gnu-emacs@gnu.org; Fri, 16 Mar 2012 20:10:13 -0400 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q2H0A9r8002325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 17 Mar 2012 00:10:10 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q2H0A8uR000261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 17 Mar 2012 00:10:09 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q2H0A8xs019582 for ; Fri, 16 Mar 2012 19:10:08 -0500 Received: from dradamslap1 (/10.159.47.64) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 16 Mar 2012 17:10:08 -0700 From: "Drew Adams" To: Subject: 24.0.94; icomplete with multiline candidates and standalone minibuffer Date: Fri, 16 Mar 2012 17:10:04 -0700 Message-ID: <56626A33CFEC4F62B686BEBB6D722F6C@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac0D0k17k+aoO9W7R9SGgXvUZS8ErA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-CT-RefId: str=0001.0A090204.4F63D662.005F,ss=1,re=0.000,fgs=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 208.118.235.17 X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) 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' From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 17 09:24:44 2012 Received: (at 11035) by debbugs.gnu.org; 17 Mar 2012 13:24:44 +0000 Received: from localhost ([127.0.0.1]:54513 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S8tci-00040V-6p for submit@debbugs.gnu.org; Sat, 17 Mar 2012 09:24:44 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:46816) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S8tcW-00040G-Vg for 11035@debbugs.gnu.org; Sat, 17 Mar 2012 09:24:43 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0M1100D0051DIB00@a-mtaout22.012.net.il> for 11035@debbugs.gnu.org; Sat, 17 Mar 2012 14:53:20 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.127.116.86]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M1100D9G54V7RA0@a-mtaout22.012.net.il>; Sat, 17 Mar 2012 14:53:20 +0200 (IST) Date: Sat, 17 Mar 2012 14:53:20 +0200 From: Eli Zaretskii Subject: Re: bug#11035: 24.0.94; icomplete with multiline candidates and standalone minibuffer In-reply-to: <56626A33CFEC4F62B686BEBB6D722F6C@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83pqcb2xtr.fsf@gnu.org> References: <56626A33CFEC4F62B686BEBB6D722F6C@us.oracle.com> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 11035 Cc: 11035@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: "Drew Adams" > 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 17 11:28:01 2012 Received: (at 11035) by debbugs.gnu.org; 17 Mar 2012 15:28:01 +0000 Received: from localhost ([127.0.0.1]:54777 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S8vY0-0007fA-QK for submit@debbugs.gnu.org; Sat, 17 Mar 2012 11:28:01 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:41146) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S8vXx-0007f2-LI for 11035@debbugs.gnu.org; Sat, 17 Mar 2012 11:27:58 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0M1100E00AO8HK00@a-mtaout22.012.net.il> for 11035@debbugs.gnu.org; Sat, 17 Mar 2012 16:57:32 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.229.34.45]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M1100E86AVU0UB0@a-mtaout22.012.net.il>; Sat, 17 Mar 2012 16:57:32 +0200 (IST) Date: Sat, 17 Mar 2012 16:57:31 +0200 From: Eli Zaretskii Subject: Re: bug#11035: 24.0.94; icomplete with multiline candidates and standalone minibuffer In-reply-to: <83pqcb2xtr.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: Stefan Monnier , Chong Yidong Message-id: <83limz2s2s.fsf@gnu.org> References: <56626A33CFEC4F62B686BEBB6D722F6C@us.oracle.com> <83pqcb2xtr.fsf@gnu.org> X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 11035 Cc: 11035@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.5 (/) > Date: Sat, 17 Mar 2012 14:53:20 +0200 > From: Eli Zaretskii > 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; } } From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 17 11:39:08 2012 Received: (at 11035) by debbugs.gnu.org; 17 Mar 2012 15:39:08 +0000 Received: from localhost ([127.0.0.1]:54794 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S8vil-0007vy-N6 for submit@debbugs.gnu.org; Sat, 17 Mar 2012 11:39:08 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:44592) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S8viZ-0007vI-2R for 11035@debbugs.gnu.org; Sat, 17 Mar 2012 11:39:05 -0400 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q2HF8Xbs027921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 17 Mar 2012 15:08:34 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q2HF8Wr2013001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 Mar 2012 15:08:32 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q2HF8Vux001819; Sat, 17 Mar 2012 10:08:31 -0500 Received: from dradamslap1 (/10.159.43.228) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 17 Mar 2012 08:08:31 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" , "'Stefan Monnier'" , "'Chong Yidong'" References: <56626A33CFEC4F62B686BEBB6D722F6C@us.oracle.com> <83pqcb2xtr.fsf@gnu.org> <83limz2s2s.fsf@gnu.org> Subject: RE: bug#11035: 24.0.94; icomplete with multiline candidates and standalone minibuffer Date: Sat, 17 Mar 2012 08:08:25 -0700 Message-ID: <16B62E86D88444A7AB7A82E1B2988AE1@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83limz2s2s.fsf@gnu.org> Thread-Index: Ac0ETkqmjID48phxSVGgpvHZKoC+IgAAIUAw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-CT-RefId: str=0001.0A090203.4F64A8F2.007F,ss=1,re=0.000,fgs=0 X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11035 Cc: 11035@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 17 11:39:10 2012 Received: (at 11035) by debbugs.gnu.org; 17 Mar 2012 15:39:11 +0000 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 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 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 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 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 Received: from dradamslap1 (/10.159.43.228) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 17 Mar 2012 08:08:32 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" References: <56626A33CFEC4F62B686BEBB6D722F6C@us.oracle.com> <83pqcb2xtr.fsf@gnu.org> Subject: RE: 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> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11035 Cc: 11035@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > > 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 17 14:48:01 2012 Received: (at 11035) by debbugs.gnu.org; 17 Mar 2012 18:48:01 +0000 Received: from localhost ([127.0.0.1]:54953 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S8yfY-0003rR-VE for submit@debbugs.gnu.org; Sat, 17 Mar 2012 14:48:01 -0400 Received: from mtaout23.012.net.il ([80.179.55.175]:56390) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S8yfW-0003rH-5y for 11035@debbugs.gnu.org; Sat, 17 Mar 2012 14:47:59 -0400 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0M1100300K1JRQ00@a-mtaout23.012.net.il> for 11035@debbugs.gnu.org; Sat, 17 Mar 2012 20:17:36 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.229.34.45]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M1100310K55N180@a-mtaout23.012.net.il>; Sat, 17 Mar 2012 20:17:34 +0200 (IST) Date: Sat, 17 Mar 2012 20:17:29 +0200 From: Eli Zaretskii Subject: Re: bug#11035: 24.0.94; icomplete with multiline candidates and standalone minibuffer In-reply-to: <16B62E86D88444A7AB7A82E1B2988AE1@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83ehsr2iti.fsf@gnu.org> References: <56626A33CFEC4F62B686BEBB6D722F6C@us.oracle.com> <83pqcb2xtr.fsf@gnu.org> <83limz2s2s.fsf@gnu.org> <16B62E86D88444A7AB7A82E1B2988AE1@us.oracle.com> X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 11035 Cc: 11035@debbugs.gnu.org, cyd@stupidchicken.com, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.5 (/) > From: "Drew Adams" > 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 17 15:01:19 2012 Received: (at 11035) by debbugs.gnu.org; 17 Mar 2012 19:01:19 +0000 Received: from localhost ([127.0.0.1]:54957 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S8ysQ-0004BB-Cc for submit@debbugs.gnu.org; Sat, 17 Mar 2012 15:01:18 -0400 Received: from mtaout23.012.net.il ([80.179.55.175]:57556) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S8ysE-0004At-7J for 11035@debbugs.gnu.org; Sat, 17 Mar 2012 15:01:17 -0400 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0M1100300KNBSM00@a-mtaout23.012.net.il> for 11035@debbugs.gnu.org; Sat, 17 Mar 2012 20:30:44 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.229.34.45]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M110034NKR6T000@a-mtaout23.012.net.il>; Sat, 17 Mar 2012 20:30:43 +0200 (IST) Date: Sat, 17 Mar 2012 20:30:43 +0200 From: Eli Zaretskii Subject: Re: bug#11035: 24.0.94; icomplete with multiline candidates and standalone minibuffer In-reply-to: <24D5DCA1F5CC4998B913A2618831F2BB@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <83d38b2i7g.fsf@gnu.org> References: <56626A33CFEC4F62B686BEBB6D722F6C@us.oracle.com> <83pqcb2xtr.fsf@gnu.org> <24D5DCA1F5CC4998B913A2618831F2BB@us.oracle.com> X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 11035 Cc: 11035@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.5 (/) > From: "Drew Adams" > 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 17 16:44:20 2012 Received: (at 11035) by debbugs.gnu.org; 17 Mar 2012 20:44:20 +0000 Received: from localhost ([127.0.0.1]:55012 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S90U7-0006XH-I8 for submit@debbugs.gnu.org; Sat, 17 Mar 2012 16:44:20 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:47617) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S90Tu-0006Wz-VU for 11035@debbugs.gnu.org; Sat, 17 Mar 2012 16:44:18 -0400 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q2HKDi5F021503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 17 Mar 2012 20:13:45 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q2HKDhuN008946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 Mar 2012 20:13:44 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q2HKDgNh022902; Sat, 17 Mar 2012 15:13:43 -0500 Received: from dradamslap1 (/10.159.43.228) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 17 Mar 2012 13:13:42 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" References: <56626A33CFEC4F62B686BEBB6D722F6C@us.oracle.com> <83pqcb2xtr.fsf@gnu.org> <24D5DCA1F5CC4998B913A2618831F2BB@us.oracle.com> <83d38b2i7g.fsf@gnu.org> Subject: RE: bug#11035: 24.0.94; icomplete with multiline candidates and standalone minibuffer Date: Sat, 17 Mar 2012 13:13:36 -0700 Message-ID: <6572286833D84E5AAECCE4A6A8C47980@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83d38b2i7g.fsf@gnu.org> Thread-Index: Ac0EbBKuKhujVTieTm2W64L897AyfgACd7dA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-CT-RefId: str=0001.0A090205.4F64F079.005B,ss=1,re=0.000,fgs=0 X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11035 Cc: 11035@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 17 17:18:17 2012 Received: (at 11035) by debbugs.gnu.org; 17 Mar 2012 21:18:17 +0000 Received: from localhost ([127.0.0.1]:55065 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S910y-0008Aj-HN for submit@debbugs.gnu.org; Sat, 17 Mar 2012 17:18:16 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:62804) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S910u-0008Aa-9I for 11035@debbugs.gnu.org; Sat, 17 Mar 2012 17:18:13 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0M1100600QVAKA00@a-mtaout21.012.net.il> for 11035@debbugs.gnu.org; Sat, 17 Mar 2012 22:47:50 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.229.34.45]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M11006BGR3PFR90@a-mtaout21.012.net.il>; Sat, 17 Mar 2012 22:47:50 +0200 (IST) Date: Sat, 17 Mar 2012 22:47:50 +0200 From: Eli Zaretskii Subject: Re: bug#11035: 24.0.94; icomplete with multiline candidates and standalone minibuffer In-reply-to: <6572286833D84E5AAECCE4A6A8C47980@us.oracle.com> X-012-Sender: halo1@inter.net.il To: Drew Adams Message-id: <838viz2bux.fsf@gnu.org> References: <56626A33CFEC4F62B686BEBB6D722F6C@us.oracle.com> <83pqcb2xtr.fsf@gnu.org> <24D5DCA1F5CC4998B913A2618831F2BB@us.oracle.com> <83d38b2i7g.fsf@gnu.org> <6572286833D84E5AAECCE4A6A8C47980@us.oracle.com> X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 11035 Cc: 11035@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.5 (/) > From: "Drew Adams" > 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 17 18:14:15 2012 Received: (at 11035) by debbugs.gnu.org; 17 Mar 2012 22:14:15 +0000 Received: from localhost ([127.0.0.1]:55076 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S91t8-00010e-MO for submit@debbugs.gnu.org; Sat, 17 Mar 2012 18:14:14 -0400 Received: from rcsinet15.oracle.com ([148.87.113.117]:28450) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S91sx-00010N-Dd for 11035@debbugs.gnu.org; Sat, 17 Mar 2012 18:14:13 -0400 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q2HLhea8011452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 17 Mar 2012 21:43:41 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q2HLhdDb005746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 Mar 2012 21:43:40 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q2HLhdkB002657; Sat, 17 Mar 2012 16:43:39 -0500 Received: from dradamslap1 (/10.159.43.228) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 17 Mar 2012 14:43:39 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" References: <56626A33CFEC4F62B686BEBB6D722F6C@us.oracle.com> <83pqcb2xtr.fsf@gnu.org> <24D5DCA1F5CC4998B913A2618831F2BB@us.oracle.com> <83d38b2i7g.fsf@gnu.org> <6572286833D84E5AAECCE4A6A8C47980@us.oracle.com> <838viz2bux.fsf@gnu.org> Subject: RE: bug#11035: 24.0.94; icomplete with multiline candidates and standalone minibuffer Date: Sat, 17 Mar 2012 14:43:32 -0700 Message-ID: <13C00143AAE24FB6BC5D3ECE1C1EC6F4@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <838viz2bux.fsf@gnu.org> Thread-Index: Ac0EfznCACv2amrkR62NNJl+jmQFIgABaLzg 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.4F65058D.007C,ss=1,re=0.000,fgs=0 X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11035 Cc: 11035@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 17 21:45:17 2012 Received: (at 11035) by debbugs.gnu.org; 18 Mar 2012 01:45:17 +0000 Received: from localhost ([127.0.0.1]:55142 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S95BM-0005q4-Fq for submit@debbugs.gnu.org; Sat, 17 Mar 2012 21:45:17 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.183]:1371) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S95BJ-0005pu-J9 for 11035@debbugs.gnu.org; Sat, 17 Mar 2012 21:45:14 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAKU/KE9soXdS/2dsb2JhbACBX5x7eYhwnhmGGQSbGYQJ X-IronPort-AV: E=Sophos;i="4.73,1,1325480400"; d="scan'208";a="168635718" Received: from 108-161-119-82.dsl.teksavvy.com (HELO pastel.home) ([108.161.119.82]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 17 Mar 2012 21:14:50 -0400 Received: by pastel.home (Postfix, from userid 20848) id B360F5946A; Sat, 17 Mar 2012 21:14:50 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#11035: 24.0.94; icomplete with multiline candidates and standalone minibuffer Message-ID: References: <56626A33CFEC4F62B686BEBB6D722F6C@us.oracle.com> <83pqcb2xtr.fsf@gnu.org> <83limz2s2s.fsf@gnu.org> Date: Sat, 17 Mar 2012 21:14:50 -0400 In-Reply-To: <83limz2s2s.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 17 Mar 2012 16:57:31 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 11035 Cc: 11035@debbugs.gnu.org, Chong Yidong , drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 17 22:19:47 2012 Received: (at 11035) by debbugs.gnu.org; 18 Mar 2012 02:19:47 +0000 Received: from localhost ([127.0.0.1]:55152 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S95ik-0006bR-Ri for submit@debbugs.gnu.org; Sat, 17 Mar 2012 22:19:47 -0400 Received: from acsinet15.oracle.com ([141.146.126.227]:44675) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S95iZ-0006b8-M8 for 11035@debbugs.gnu.org; Sat, 17 Mar 2012 22:19:45 -0400 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q2I1nBup014087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 18 Mar 2012 01:49:12 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q2I1nAPZ010425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Mar 2012 01:49:10 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q2I1n9nL023289; Sat, 17 Mar 2012 20:49:09 -0500 Received: from dradamslap1 (/10.159.45.19) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 17 Mar 2012 18:49:09 -0700 From: "Drew Adams" To: "'Stefan Monnier'" , "'Eli Zaretskii'" References: <56626A33CFEC4F62B686BEBB6D722F6C@us.oracle.com><83pqcb2xtr.fsf@gnu.org> <83limz2s2s.fsf@gnu.org> Subject: RE: bug#11035: 24.0.94; icomplete with multiline candidates and standalone minibuffer Date: Sat, 17 Mar 2012 18:49:00 -0700 Message-ID: <9BE2B0B1BB76452D87B0A7627BDCD1B0@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Ac0EpIZs1GEPUdsSTn2E1JeFRGnUgwABLP2w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4F653F18.0035,ss=1,re=0.000,fgs=0 X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 11035 Cc: 11035@debbugs.gnu.org, 'Chong Yidong' X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) > > 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. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 18 13:31:06 2012 Received: (at 11035-done) by debbugs.gnu.org; 18 Mar 2012 17:31:06 +0000 Received: from localhost ([127.0.0.1]:55822 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S9Jwd-0002mb-U4 for submit@debbugs.gnu.org; Sun, 18 Mar 2012 13:31:05 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:42058) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S9JwP-0002lz-8m for 11035-done@debbugs.gnu.org; Sun, 18 Mar 2012 13:31:01 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0M1300700B4NPC00@a-mtaout22.012.net.il> for 11035-done@debbugs.gnu.org; Sun, 18 Mar 2012 18:59:49 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.229.132.55]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M130041JB7O4U71@a-mtaout22.012.net.il>; Sun, 18 Mar 2012 18:59:49 +0200 (IST) Date: Sun, 18 Mar 2012 18:59:50 +0200 From: Eli Zaretskii Subject: Re: bug#11035: 24.0.94; icomplete with multiline candidates and standalone minibuffer In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <8362e13kvt.fsf@gnu.org> References: <56626A33CFEC4F62B686BEBB6D722F6C@us.oracle.com> <83pqcb2xtr.fsf@gnu.org> <83limz2s2s.fsf@gnu.org> X-Spam-Score: -1.2 (-) X-Debbugs-Envelope-To: 11035-done Cc: cyd@stupidchicken.com, 11035-done@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: Stefan Monnier > Cc: Chong Yidong , 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. From unknown Fri Sep 05 20:36:41 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 16 Apr 2012 11:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator