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: Tue, 25 Aug 2015 18:12:39 +0300 Message-ID: <83oahvfllk.fsf@gnu.org> References: <83k2skhhz1.fsf@gnu.org> <83twrofr0u.fsf@gnu.org> <55DC185A.4080101@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Trace: ger.gmane.org 1440515940 5577 80.91.229.3 (25 Aug 2015 15:19:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 25 Aug 2015 15:19:00 +0000 (UTC) Cc: pipcet@gmail.com, 21333@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Aug 25 17:18:51 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 1ZUFzo-00070V-0x for geb-bug-gnu-emacs@m.gmane.org; Tue, 25 Aug 2015 17:18:44 +0200 Original-Received: from localhost ([::1]:60875 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUFzn-000513-JY for geb-bug-gnu-emacs@m.gmane.org; Tue, 25 Aug 2015 11:18:43 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39874) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUFuP-0005vQ-Bw for bug-gnu-emacs@gnu.org; Tue, 25 Aug 2015 11:13:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZUFuJ-0001VU-0H for bug-gnu-emacs@gnu.org; Tue, 25 Aug 2015 11:13:09 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:45959) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUFuI-0001VQ-SD for bug-gnu-emacs@gnu.org; Tue, 25 Aug 2015 11:13:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZUFuI-0005K2-I1 for bug-gnu-emacs@gnu.org; Tue, 25 Aug 2015 11:13: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: Tue, 25 Aug 2015 15:13:02 +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.144051557520443 (code B ref 21333); Tue, 25 Aug 2015 15:13:02 +0000 Original-Received: (at 21333) by debbugs.gnu.org; 25 Aug 2015 15:12:55 +0000 Original-Received: from localhost ([127.0.0.1]:38169 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUFuA-0005Jf-94 for submit@debbugs.gnu.org; Tue, 25 Aug 2015 11:12:54 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:33493) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUFu7-0005JV-Fe for 21333@debbugs.gnu.org; Tue, 25 Aug 2015 11:12:52 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NTN001008QJIG00@a-mtaout22.012.net.il> for 21333@debbugs.gnu.org; Tue, 25 Aug 2015 18:12:50 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NTN001VO8XDBB30@a-mtaout22.012.net.il>; Tue, 25 Aug 2015 18:12:50 +0300 (IDT) In-reply-to: <55DC185A.4080101@gmx.at> 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:105802 Archived-At: > Date: Tue, 25 Aug 2015 09:25:14 +0200 > From: martin rudalics > CC: 21333@debbugs.gnu.org > > > But the coordinates of the text that stays on screen don't change in > > such a resize. Some text is obscured, but what's left doesn't move. > > So I see no problem here. > > I'm not sure what you mean here: When the minibuffer resizes and point > is near the bottom of the window above, the window above will scroll and > stick to the new window start position even after the minibuffer gets > sized back. When the window above the minibuffer is a one line window > or fixed-size, the window above that window will be subject to those > changes. In these two cases, yes. In all the others (which are vast majority), no. And I'm still not sure I understand the relevance. How exactly knowing about the automatic resize will help with coordinates in this case? If the Lisp program recomputes coordinates inside the hook, it will get the same results in most cases (when point is not in the obscured lines). So an alternative that doesn't need any hook is simply to recompute the coordinates every time they are needed. It's not like this calculation is expensive, is it? > > No, it's not. It's the same issue: this hook is already called in > > situations where it shouldn't have been, and thus imposes on the > > programmers who use it complex ways of deciding whether there was or > > wasn't a change they should care about. You suggest to add one more > > situation in that class, something that most application that define > > this hook shouldn't and don't care. It's the complexity that worries > > me. > > You mean when ‘set-window-configuration’ doesn't change the size of a > single window the hook shouldn't be called? Yes, of course. > Ideally it shouldn't but this is a problem similar to that of > indenting a paragraph changing the buffer modified state although in > reality nothing changed. And we get regular complaints about that as well. Moreover, the setting of the modified status by fill-paragraph is just an annoyance that doesn't cost anyone any extra complexity, whereas the situation with this and similar hooks costs us quite a lot in that aspect.