From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#43519: 28.0.50; Overlay at end of minibuf hides minibuf's real content Date: Sat, 19 Sep 2020 23:10:36 +0300 Message-ID: <83r1qx1q9v.fsf@gnu.org> References: <83wo0p1twr.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23802"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 43519@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Sep 19 22:11:23 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kJjCc-00065U-Bl for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 19 Sep 2020 22:11:22 +0200 Original-Received: from localhost ([::1]:49930 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kJjCb-0007y0-7n for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 19 Sep 2020 16:11:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37626) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kJjCI-0007xm-9D for bug-gnu-emacs@gnu.org; Sat, 19 Sep 2020 16:11:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36630) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kJjCH-0002e5-W5 for bug-gnu-emacs@gnu.org; Sat, 19 Sep 2020 16:11:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kJjCH-0007v6-Qi for bug-gnu-emacs@gnu.org; Sat, 19 Sep 2020 16:11:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 19 Sep 2020 20:11:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43519 X-GNU-PR-Package: emacs Original-Received: via spool by 43519-submit@debbugs.gnu.org id=B43519.160054625130429 (code B ref 43519); Sat, 19 Sep 2020 20:11:01 +0000 Original-Received: (at 43519) by debbugs.gnu.org; 19 Sep 2020 20:10:51 +0000 Original-Received: from localhost ([127.0.0.1]:48176 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kJjC7-0007ui-IW for submit@debbugs.gnu.org; Sat, 19 Sep 2020 16:10:51 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:59036) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kJjC6-0007uV-Il for 43519@debbugs.gnu.org; Sat, 19 Sep 2020 16:10:51 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:51430) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kJjBz-0002XE-D3; Sat, 19 Sep 2020 16:10:44 -0400 Original-Received: from [176.228.60.248] (port=3485 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kJjBu-0000oe-Pf; Sat, 19 Sep 2020 16:10:42 -0400 In-Reply-To: (message from Stefan Monnier on Sat, 19 Sep 2020 15:42:12 -0400) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:188435 Archived-At: > From: Stefan Monnier > Cc: 43519@debbugs.gnu.org > Date: Sat, 19 Sep 2020 15:42:12 -0400 > > > Seems like a bug in icomplete: it attempts to compute the maximum > > length of candidates to be displayed, but seems like it fails, because > > the single mini-window line is continued, with no ellipsis at the end > > of the visible line? > > I disagree: icomplete merely added text after point via an overlay and > didn't do anything which explicitly justifies horizontal scrolling. Maybe I'm missing something, but what does the code in icomplete-completions that calls string-width and window-width try to do, then? I mean this part: ;;"-prospects" - more than one candidate (prospects-len (+ (string-width (or determ (concat open-bracket close-bracket))) (string-width icomplete-separator) (+ 2 (string-width ellipsis)) ;; take {…} into account (string-width (buffer-string)))) (prospects-max ;; Max total length to use, including the minibuffer content. (* (+ icomplete-prospects-height ;; If the minibuffer content already uses up more than ;; one line, increase the allowable space accordingly. (/ prospects-len (window-width))) (window-width))) > I suspect the problem is that point is right on the overlay, so in > a sense it's both before *and* after the "{...}" text. The point is at EOB, and we have an overlay string there. The overlay string has a 'cursor' property on its first character, so the display engine puts the cursor there. Without that, we'd have the cursor at the end of the overlay string, thus showing something even less reasonable. But I'm not sure how this is related to the issue at hand. > > It should produce an overlay string that fits in the window, then the > > prompt will be visible. > > That would merely work around the underlying problem What do you think is the underlying problem? > (and as you know it's wickedly difficult to construct a string which > will have "just the right size" to fit into the minibuffer window). It doesn't have to be "just the right size", it could err on the safe side. It already attempts to do so, by avoiding truncation in the middle of a candidate. It should just do a better job, that's all. > Maybe there's a good reason for the redisplay to behave this way Behave in what way? what's special about what you see on display in this case, given the contents of the mini-window's buffer?