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#43572: Feature request: make it possible to choose whether the first lines of the minibuffer should be displayed instead of the last ones Date: Fri, 25 Sep 2020 08:34:50 +0000 Message-ID: References: <83h7rov7xy.fsf@gnu.org> <837dskuvx3.fsf@gnu.org> <833637uubc.fsf@gnu.org> <83mu1ftdkb.fsf@gnu.org> <83imc3tach.fsf@gnu.org> <83eemrt8da.fsf@gnu.org> <838scytk87.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="12559"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Alpine 2.22 (NEB 394 2020-01-19) Cc: 43572@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Sep 25 10:35:20 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 1kLjCJ-00038K-S4 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 25 Sep 2020 10:35:19 +0200 Original-Received: from localhost ([::1]:41802 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kLjCI-0006b9-TA for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 25 Sep 2020 04:35:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48558) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kLjC2-0006YR-3w for bug-gnu-emacs@gnu.org; Fri, 25 Sep 2020 04:35:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:59231) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kLjC1-000359-Oy for bug-gnu-emacs@gnu.org; Fri, 25 Sep 2020 04:35:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kLjC1-0005L3-K3 for bug-gnu-emacs@gnu.org; Fri, 25 Sep 2020 04:35:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gregory Heytings Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 25 Sep 2020 08:35:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43572 X-GNU-PR-Package: emacs Original-Received: via spool by 43572-submit@debbugs.gnu.org id=B43572.160102289820509 (code B ref 43572); Fri, 25 Sep 2020 08:35:01 +0000 Original-Received: (at 43572) by debbugs.gnu.org; 25 Sep 2020 08:34:58 +0000 Original-Received: from localhost ([127.0.0.1]:42544 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kLjBx-0005Ki-T2 for submit@debbugs.gnu.org; Fri, 25 Sep 2020 04:34:58 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:57891) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kLjBu-0005KY-Q3 for 43572@debbugs.gnu.org; Fri, 25 Sep 2020 04:34:56 -0400 Original-Received: from sdf.org (IDENT:ghe@otaku.sdf.org [205.166.94.8]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 08P8YruW020003 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Fri, 25 Sep 2020 08:34:53 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 08P8Z8bN029886; Fri, 25 Sep 2020 08:35:08 GMT In-Reply-To: <838scytk87.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:188928 Archived-At: >> I'm not sure I understand what you mean, but it seems to me that these >> other uses of the mini-window are not at all affected by the proposed >> patch, given that `start-display-at-beginning-of-minibuffer' is reset >> immediately when read_minibuf() / read-from-minibuffer has ended. > > I remind you the fact that read_minibuf enters recursive-edit, during > which any of the other callers of resize_mini_window can be called. > Now I think I understand what you mean. Mini-windows are used for minibuffers and for the echo area. So for example, when `start-display-at-beginning-of-minibuffer' is set while icomplete is active in a frame, a call to `message' in another frame will display the first part of the string instead of its last part if the string is too large. This seems like a really minor problem. >>> And even in its use for the minibuffer, many users enable recursive >>> minibuffers. I would not be surprised if some specialized modes and >>> packages enabled it for their operations. >> >> If this case is important, the attached corrected patch also disables >> setting `start-display-at-beginning-of-minibuffer' in recursive >> minibuffers, that is, it limits the effect of that variable to >> non-recursive minibuffers. > > That's a limitation I'd prefer not to impose. > I would also prefer not to impose that limitation, I added it because you asked it (or at least that's what I understood). I think the second patch I sent is the best and simplest one. I do agree with you that it's an ad-hoc solution, but there are other such ad-hoc solutions in Emacs, for example the `minibuffer-completing-file-name' variable, which even uses a "neither true nor false" intermediate state in recursive minibuffers. Anyway, I won't argue further, at this point it seems clear that you don't want the patch I proposed. A remark on what you wrote yesterday: > > I'm not claiming that the changes I made yesterday and today are > supposed to produce the same effect as your proposed patch. I'm just > making the display with overlay-string behave (as much as possible) like > display with normal buffer text, that's all. Per bug#43519. I'm not > saying that my changes implement the feature you are asking for here. > In fact these changes are, IMO, very regrettable, because they solve 95% of the problems that have been discussed in bug#24293, bug#39379, bug#43519 and bug#43572 (and perhaps others), and the remaining 5% will have to be solved another way (by text properties if that's what you agree on with Stefan). This means that those who were trying to solve the problems in the above-mentioned bugs will be misled in thinking that they are now solved (if they don't immediately see these remaining 5%), and to not make the effort to use the (not yet implemented) correct solution. I don't think you will do this, but please, please: revert these changes. >> I'll wait until you and Stefan agree on the way to solve that problem >> in a better way to start working on this. In his last mail he is >> apparently not sure anymore that using text properties to do this, as >> he suggested yesterday, is the best solution. > > Yes, I'm still unsure why Stefan said that, and am waiting for his > elaborations. > Okay, I'm waiting for the conclusion of that discussion.