From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#11035: 24.0.94; icomplete with multiline candidates and standalone minibuffer Date: Sat, 17 Mar 2012 14:53:20 +0200 Message-ID: <83pqcb2xtr.fsf@gnu.org> References: <56626A33CFEC4F62B686BEBB6D722F6C@us.oracle.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: dough.gmane.org 1331988899 18211 80.91.229.3 (17 Mar 2012 12:54:59 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 17 Mar 2012 12:54:59 +0000 (UTC) Cc: 11035@debbugs.gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Mar 17 13:54:57 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 1S8t9m-0005rP-Uh for geb-bug-gnu-emacs@m.gmane.org; Sat, 17 Mar 2012 13:54:51 +0100 Original-Received: from localhost ([::1]:50205 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8t9l-0000pV-W5 for geb-bug-gnu-emacs@m.gmane.org; Sat, 17 Mar 2012 08:54:49 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:51371) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8t9i-0000oS-MW for bug-gnu-emacs@gnu.org; Sat, 17 Mar 2012 08:54:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S8t9g-0002oW-2F for bug-gnu-emacs@gnu.org; Sat, 17 Mar 2012 08:54:46 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:47681) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8t9f-0002oR-V2 for bug-gnu-emacs@gnu.org; Sat, 17 Mar 2012 08:54:43 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1S8td0-000417-Bl for bug-gnu-emacs@gnu.org; Sat, 17 Mar 2012 09:25:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 17 Mar 2012 13:25: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.133199068415410 (code B ref 11035); Sat, 17 Mar 2012 13:25:02 +0000 Original-Received: (at 11035) by debbugs.gnu.org; 17 Mar 2012 13:24:44 +0000 Original-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 Original-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 Original-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) Original-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) In-reply-to: <56626A33CFEC4F62B686BEBB6D722F6C@us.oracle.com> X-012-Sender: halo1@inter.net.il 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:57849 Archived-At: > 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.