From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize Date: Thu, 27 Aug 2015 21:35:10 +0300 Message-ID: <8337z460m9.fsf@gnu.org> References: <83k2skhhz1.fsf@gnu.org> <55DB5D3E.1000706@gmx.at> <83vbc4fsjd.fsf@gnu.org> <55DC1856.7000501@gmx.at> <83pp2bfln1.fsf@gnu.org> <55DD662A.8080201@gmx.at> <83si765aqv.fsf@gnu.org> <55DEC2DB.9080800@gmx.at> <83a8tc6988.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1440700598 7251 80.91.229.3 (27 Aug 2015 18:36:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 27 Aug 2015 18:36:38 +0000 (UTC) Cc: 21333@debbugs.gnu.org To: Pip Cet Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Aug 27 20:36:27 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZV21z-0007qE-V1 for geb-bug-gnu-emacs@m.gmane.org; Thu, 27 Aug 2015 20:36:12 +0200 Original-Received: from localhost ([::1]:44113 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZV21z-0007Hq-9j for geb-bug-gnu-emacs@m.gmane.org; Thu, 27 Aug 2015 14:36:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51634) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZV21u-0007ET-0D for bug-gnu-emacs@gnu.org; Thu, 27 Aug 2015 14:36:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZV21p-0001RY-RS for bug-gnu-emacs@gnu.org; Thu, 27 Aug 2015 14:36:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:48330) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZV21p-0001RG-P3 for bug-gnu-emacs@gnu.org; Thu, 27 Aug 2015 14:36:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZV21p-00085a-Ll for bug-gnu-emacs@gnu.org; Thu, 27 Aug 2015 14:36: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: Thu, 27 Aug 2015 18:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21333 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21333-submit@debbugs.gnu.org id=B21333.144070051331036 (code B ref 21333); Thu, 27 Aug 2015 18:36:01 +0000 Original-Received: (at 21333) by debbugs.gnu.org; 27 Aug 2015 18:35:13 +0000 Original-Received: from localhost ([127.0.0.1]:40540 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZV213-00084W-38 for submit@debbugs.gnu.org; Thu, 27 Aug 2015 14:35:13 -0400 Original-Received: from mtaout28.012.net.il ([80.179.55.184]:38830) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZV210-00084N-H1 for 21333@debbugs.gnu.org; Thu, 27 Aug 2015 14:35:11 -0400 Original-Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NTR009007DVK900@mtaout28.012.net.il> for 21333@debbugs.gnu.org; Thu, 27 Aug 2015 21:35:02 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NTR00AJS7MD1A00@mtaout28.012.net.il>; Thu, 27 Aug 2015 21:35:02 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 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.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:105888 Archived-At: > Date: Thu, 27 Aug 2015 17:05:35 +0000 > From: Pip Cet > Cc: martin rudalics , 21333@debbugs.gnu.org > > > Since mini-window resizing can persistently > > change the end position of the first of these windows > > Any command that clears the echo area will resize it back, AFAIK. So > it's not persistent. > > > That's not what I'm seeing here. When I run: > > (progn > (run-with-timer 2 nil (lambda () (message "hi"))) > (run-with-timer 3 nil (lambda () (message ""))) > (read-from-minibuffer (make-string 3000 ?*))) > > The minibuffer resizes once, when the read-from-minibuffer prompt makes it grow > to its maximal size; it then stays at that size as the short message is being > displayed, then restores the long minibuffer prompt without changing size again > when the echo area is cleared. That's a different situation, quite bizarre btw. Just run normal code, like only the message above, then move the cursor, and you will see the echo area shrink back. That's the normal use case. > > OT1H we do care about point being visible when its window is partially > > obscured by the mini-window and deliberately scroll the window in that > > case. OTOH we'd say that `follow-mode' should not care about keeping > > its text coherent in that case. Is that fair? > > Yes. In that situation, the user most probably reads the mini-window > text anyway, and if not, then she reads the text at point. The > probability that she is reading the text that will be scrolled out of > view as result of the mini-window resize is IMO minuscule. > > So if, for whatever reason, I have a timer function that displays a two-line > message once a second (so the echo area never goes back to its single-line > state), my follow-mode buffer will be and remain in an inconsistent state until > I manually resize a window, when it will go back to a consistent state, but > then if I cancel the timer (and the mini-window shrinks) it'll be in an > inconsistent state again, and the only way out of that one is another manual > window resize? I'd say just don't do that, it's terribly annoying to see such display even without the other issues. > I think that last case is something we haven't considered yet: if I resize > windows manually while the mini-window is enlarged, they will be in an > inconsistent state when it goes back to normal, right? What do you mean by "inconsistent state"?