From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings via "Bug reports for GNU Emacs, the Swiss army knife of text editors" 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 16:27:51 +0000 Message-ID: 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> Reply-To: Gregory Heytings Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37694"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Alpine 2.22 (NEB 394 2020-01-19) Cc: monnier@iro.umontreal.ca, 43519@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Sep 21 18:32:14 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 1kKOje-0009gE-4N for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 21 Sep 2020 18:32:14 +0200 Original-Received: from localhost ([::1]:36456 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kKOjd-0005We-5j for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 21 Sep 2020 12:32:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56680) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kKOfd-0003eB-GM for bug-gnu-emacs@gnu.org; Mon, 21 Sep 2020 12:28:08 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44440) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kKOfa-0007BE-HX for bug-gnu-emacs@gnu.org; Mon, 21 Sep 2020 12:28:05 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kKOfa-0001bu-E6 for bug-gnu-emacs@gnu.org; Mon, 21 Sep 2020 12:28:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gregory Heytings Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Sep 2020 16:28: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.16007056796182 (code B ref 43519); Mon, 21 Sep 2020 16:28:02 +0000 Original-Received: (at 43519) by debbugs.gnu.org; 21 Sep 2020 16:27:59 +0000 Original-Received: from localhost ([127.0.0.1]:55986 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kKOfX-0001be-GI for submit@debbugs.gnu.org; Mon, 21 Sep 2020 12:27:59 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:60227) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kKOfT-0001bU-Ie for 43519@debbugs.gnu.org; Mon, 21 Sep 2020 12:27:58 -0400 Original-Received: from sdf.org (IDENT:ghe@faeroes.freeshell.org [205.166.94.9]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 08LGRsR7017202 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 21 Sep 2020 16:27:54 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 08LGS9xu005629; Mon, 21 Sep 2020 16:28:09 GMT In-Reply-To: <83imc7xg9h.fsf@gnu.org> 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:188617 Archived-At: >> Perhaps I misunderstood something, but for me "start the display at the >> beginning of the screen line where we end up after >> move_it_vertically_backward" would mean that if the prompt and the user >> input so far needs more than one line, only the last line would be >> displayed. So instead of having, say, >> >> Find file: >> | >> >> >> (where | represents the cursor) we would only have: >> >> | >> > > Yes. > > 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. > > What I propose will do that, or as close as possible to it. By > contrast, you seem to suggest a change in the current behavior for > buffer text as well. > 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. > > 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. > > (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"? It only gives application writers the freedom to decide what Emacs should do, which is IMO a good thing in general.