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: Mon, 21 Sep 2020 20:30:40 +0300 Message-ID: <83ft7bxcjj.fsf@gnu.org> References: <83wo0p1twr.fsf@gnu.org> <83r1qx1q9v.fsf@gnu.org> <838sd425l2.fsf@gnu.org> <83tuvrxlho.fsf@gnu.org> <83mu1jxhyd.fsf@gnu.org> <83imc7xg9h.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7747"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, 43519@debbugs.gnu.org To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Sep 21 19:31:52 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 1kKPfM-0001ur-6k for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 21 Sep 2020 19:31:52 +0200 Original-Received: from localhost ([::1]:49126 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kKPfL-00051P-8U for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 21 Sep 2020 13:31:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43852) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kKPeZ-0004y9-Gh for bug-gnu-emacs@gnu.org; Mon, 21 Sep 2020 13:31:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44546) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kKPeY-0007Xk-Jn for bug-gnu-emacs@gnu.org; Mon, 21 Sep 2020 13:31:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kKPeY-0003ET-G0 for bug-gnu-emacs@gnu.org; Mon, 21 Sep 2020 13:31:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Sep 2020 17:31:02 +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.160070945112408 (code B ref 43519); Mon, 21 Sep 2020 17:31:02 +0000 Original-Received: (at 43519) by debbugs.gnu.org; 21 Sep 2020 17:30:51 +0000 Original-Received: from localhost ([127.0.0.1]:56092 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kKPeM-0003E4-Pm for submit@debbugs.gnu.org; Mon, 21 Sep 2020 13:30:51 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:36960) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kKPeK-0003Ds-TS for 43519@debbugs.gnu.org; Mon, 21 Sep 2020 13:30:49 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:33357) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kKPeF-0007O9-Hx; Mon, 21 Sep 2020 13:30:43 -0400 Original-Received: from [176.228.60.248] (port=3189 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kKPeB-0006dj-Jp; Mon, 21 Sep 2020 13:30:41 -0400 In-Reply-To: (message from Gregory Heytings on Mon, 21 Sep 2020 16:27:51 +0000) 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:188625 Archived-At: > Date: Mon, 21 Sep 2020 16:27:51 +0000 > From: Gregory Heytings > cc: monnier@iro.umontreal.ca, 43519@debbugs.gnu.org > > > This bug was filed to request that Emacs behaves with overlay-string in > > the minibuffer prompt the same as with regular buffer text. > > Hmmm... no, this bug was filed after a discussion on emacs-devel (about > implementing vertical icomplete), and the problem is clearly stated by > Stefan: the prompt and user input so far disappear. That's not my reading of the main argument, posted by Stefan in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43519#17 Some quotes: I used `icomplete-mode` only as a vehicle to show the underlying behavior with a short recipe which exhibits a real-life problem. [...] This performs "display of text after point" in 2 different ways: - first by `insert`. - then with an overlay. The visual rendering of the text is the same, with the cursor at the same place. When we do it with `insert` there is no horizontal scrolling, but when we do it with an overlay the text gets scrolled so the cursor is at `window-start`. `icomplete` needs the behavior to be the same as with `insert`, but it prefers to use an overlay to avoid some undesirable side-effects of modifying the actual text. So the question is: how to get the same behavior as what we'd get with `insert` but without actually modifying the buffer's contents? My summary of the problem raised by Stefan: . icomplete is just an example that exhibits a more general issue . the more general issue is that the display after resizing the mini-window is different depending on whether it uses plain buffer text or an after-string overlay at EOB If you use Stefan's recipe, but make the prompt much longer, like this: (minibuffer-with-setup-hook (lambda () (insert "hello") (let ((ol (make-overlay (point) (point))) (max-mini-window-height 1) (text "askdjfhaklsjdfhlkasjdfhklasdhflkasdhflkajsdhflkashdfkljahsdlfkjahsdlfkjhasldkfhalskdjfhalskdfhlaksdhfklasdhflkasdhflkasdhflkajsdhklajsdgh")) (save-excursion (insert text)) (sit-for 2) (delete-region (point) (point-max)) (put-text-property 0 1 'cursor t text) (overlay-put ol 'after-string text) (sit-for 2) (delete-overlay ol))) (read-string "totototototototototototototototototototototototototototototototototototototototototototototototototototo: ")) then in the 1st ("insert text") part of the recipe you will see only the last part of the prompt. Which is the long-standing behavior of resizing mini-windows: if the mini-window cannot be enlarged enough to show the entire text in it, we show its last part. Stefan asked for the same behavior when an overlay with after-string is used. My suggestion (I hope) will do what he asks, or approximate that as well as I think is possible under the current design of the display code. > Which is why my proposal is to not break anything, but only to give > applications the control of how what they insert in the minibuffer is > displayed. A start_display_at_beginning_of_minibuffer variable that would > be reset in read_minibuf() and that an application could set in > minibuffer-setup-hook. I don't understand why you would be opposed to > such a change. Because it changes a long-standing behavior with inserting normal text into the minibuffer. > > That may or may not be a good idea, but it's a separate issue, so should > > be discussed separately > > It's _not_ a separate issue, it's the issue at hand. I disagree, and I explained above why. > > (and in that separate discussion I will generally be opposed to the > > change you are proposing, because we had the current behavior for many > > years, and so changes like the one you propose run serious risk of > > breaking expectations of some package out there). > > > > Why would a change that does not change Emacs' behavior in any way except > if the user requests it "run serious risk of breaking expectations of some > package out there"? This is not the user, this is a Lisp program that will do it. The behavior will change in that the user will be shown only the first part of the text, as opposed to the last part we were showing until now. Maybe such a change in behavior is desirable (I'm not sure, and I don't yet have a clear idea how will Lisp programs decide which behavior to request), but it's a separate issue.