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#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 12:14:34 +0300 Message-ID: <835z82tdz9.fsf@gnu.org> 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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29464"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 43572@debbugs.gnu.org To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Sep 25 11:15:09 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 1kLjor-0007WD-HC for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 25 Sep 2020 11:15:09 +0200 Original-Received: from localhost ([::1]:43860 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kLjoq-0007aU-Iq for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 25 Sep 2020 05:15:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57424) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kLjok-0007aB-Fd for bug-gnu-emacs@gnu.org; Fri, 25 Sep 2020 05:15:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:59319) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kLjok-00088J-6S for bug-gnu-emacs@gnu.org; Fri, 25 Sep 2020 05:15:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kLjok-0006Ke-0D for bug-gnu-emacs@gnu.org; Fri, 25 Sep 2020 05:15: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: Fri, 25 Sep 2020 09:15: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.160102527224287 (code B ref 43572); Fri, 25 Sep 2020 09:15:01 +0000 Original-Received: (at 43572) by debbugs.gnu.org; 25 Sep 2020 09:14:32 +0000 Original-Received: from localhost ([127.0.0.1]:42632 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kLjoG-0006Jf-Bc for submit@debbugs.gnu.org; Fri, 25 Sep 2020 05:14:32 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:50554) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kLjoE-0006JS-9G for 43572@debbugs.gnu.org; Fri, 25 Sep 2020 05:14:30 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:51090) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kLjo8-000879-Ib; Fri, 25 Sep 2020 05:14:24 -0400 Original-Received: from [176.228.60.248] (port=3814 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kLjo7-0006xD-Ta; Fri, 25 Sep 2020 05:14:24 -0400 In-Reply-To: (message from Gregory Heytings on Fri, 25 Sep 2020 08:34:50 +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:188931 Archived-At: > Date: Fri, 25 Sep 2020 08:34:50 +0000 > From: Gregory Heytings > cc: 43572@debbugs.gnu.org > > > 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. Yes. And there are more callers of resize_mini_window than just 'message', so what you say above is just one such problematic scenario. > This seems like a really minor problem. It is still a problem, and what looks minor to us might not be minor in some valid use case out there. IME, people write code and even entire packages around some assumption about how Emacs works in specific cases. Changes that break those assumptions will not be welcome, to say the least. > >> 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 didn't ask for the limitation, I pointed out a problem with the design you were proposing. I'd prefer that the design and the implementation of this feature did not impose such limitations. Emacs generally behaves the same on any level of minibuffer recursion, and I'd like us not to violate that with this feature. > > 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). They solve the issue pointed out by Stefan in bug#43519. That they, by sheer luck, also solve some of the other issues is just that -- sheer luck. I don't claim and didn't intend to solve all the problems, in particular the issue discussed in this bug report. They are related, but different issues. > 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 really don't see why that would be the case. If someone is motivated to solve whatever is left of those other problems, they will solve them, or at least will point out which aspects of them remain unresolved. > I don't think you will do this, but please, please: revert these changes. Reverting those changes would be a very strange thing to do. Those changes solve a specific problem, and they solve it cleanly. That other problems partially remain just means more changes are necessary. In particular, the issues discussed here are a new feature which didn't exist until now; reverting fixes for an existing problem because they fail to introduce a new feature makes very little sense to me. Btw, there's nothing wrong in principle with installing a partial solution for a problem (even though that's not what I meant to do with the changes that resolve bug#43519). We can and do decide sometimes that it's a good idea to install a partial fix if the part fixed is important enough, or if a comprehensive solution is too dangerous, or for any other valid concern. This is not uncommon in Emacs development.