From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#32672: 27.0.50; image resize on window resizing Date: Tue, 25 Sep 2018 21:31:10 +0300 Message-ID: <83sh1x8m4x.fsf@gnu.org> References: <87pnxmyjgt.fsf@mail.linkov.net> <87ftyfoakb.fsf@mail.linkov.net> <5B98B33D.7000605@gmx.at> <871s9ycnjl.fsf@mail.linkov.net> <5B9A15DA.5000403@gmx.at> <87efdxnfww.fsf@mail.linkov.net> <5B9B7253.5060808@gmx.at> <87pnxexr2m.fsf@mail.linkov.net> <5B9E1E0E.7070805@gmx.at> <87h8ip2eby.fsf@mail.linkov.net> <5B9F4DBD.5020009@gmx.at> <877ejjzr9s.fsf@mail.linkov.net> <5BA20763.8070305@gmx.at> <875zz1t6y1.fsf@mail.linkov.net> <5BA34D7E.4030509@gmx.at> <87fty3sp6a.fsf@mail.linkov.net> <5BA490E5.5090506@gmx.at> <87zhw9xjpx.fsf@mail.linkov.net> <5BA74E3D.5030903@gmx.at> <87va6wt79n.fsf@mail.linkov.net> <5BA89ED5.4050207@gmx.at> <83in2vb8dw.fsf@gnu.org> <5BA8D7AB.5030106@gmx.at> <83d0t3awqt.fsf@gnu.org> <5BA920C4.1060204@gmx.at> <83r2hiaikc.fsf@gnu.org> <5BA9E337.5000806@gmx.at> <837eja9boy.fsf@gnu.org> <5BAA76B9.8090007@gmx.at> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1537900213 12547 195.159.176.226 (25 Sep 2018 18:30:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 25 Sep 2018 18:30:13 +0000 (UTC) Cc: 32672@debbugs.gnu.org, juri@linkov.net To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Sep 25 20:30:09 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g4s64-00035S-Oz for geb-bug-gnu-emacs@m.gmane.org; Tue, 25 Sep 2018 20:30:09 +0200 Original-Received: from localhost ([::1]:54754 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g4s8B-0000IT-AM for geb-bug-gnu-emacs@m.gmane.org; Tue, 25 Sep 2018 14:32:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33513) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g4s7y-0000Gt-O4 for bug-gnu-emacs@gnu.org; Tue, 25 Sep 2018 14:32:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g4s7u-00028v-Mx for bug-gnu-emacs@gnu.org; Tue, 25 Sep 2018 14:32:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:49754) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1g4s7u-00028n-Ie for bug-gnu-emacs@gnu.org; Tue, 25 Sep 2018 14:32:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1g4s7u-0007is-DU for bug-gnu-emacs@gnu.org; Tue, 25 Sep 2018 14:32: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 Sep 2018 18:32:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 32672 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 32672-submit@debbugs.gnu.org id=B32672.153790029629651 (code B ref 32672); Tue, 25 Sep 2018 18:32:02 +0000 Original-Received: (at 32672) by debbugs.gnu.org; 25 Sep 2018 18:31:36 +0000 Original-Received: from localhost ([127.0.0.1]:54012 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g4s7U-0007iB-72 for submit@debbugs.gnu.org; Tue, 25 Sep 2018 14:31:36 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:51927) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g4s7S-0007hw-EO for 32672@debbugs.gnu.org; Tue, 25 Sep 2018 14:31:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g4s7J-0001YA-7L for 32672@debbugs.gnu.org; Tue, 25 Sep 2018 14:31:29 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:35388) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g4s7I-0001Xu-Q8; Tue, 25 Sep 2018 14:31:25 -0400 Original-Received: from [176.228.60.248] (port=1504 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1g4s7H-0008QT-2U; Tue, 25 Sep 2018 14:31:24 -0400 In-reply-to: <5BAA76B9.8090007@gmx.at> (message from martin rudalics on Tue, 25 Sep 2018 19:56:09 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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" Xref: news.gmane.org gmane.emacs.bugs:150655 Archived-At: > Date: Tue, 25 Sep 2018 19:56:09 +0200 > From: martin rudalics > CC: juri@linkov.net, 32672@debbugs.gnu.org > > > Bottom line is what I said up-thread: Lisp programs cannot expect > > those hook calls to be too accurate and focused, they need to be > > prepared to handle many irrelevant calls, and they had better have > > their own bookkeeping regarding window dimensions etc. > > 'window-size-change-functions' is not hypothetical and guards itself > against running twice for unchanged window sizes. I don't really > understand what you doubt here - I rewrote it in its current form > because you once said (when discussing Bug#21333) that > > > I believe window-size-change-functions is meant for taking notice of > > resizes done by the user or some Lisp code, not for automated resizes > > whose sole purpose is to allow some message be read in its entirety. > > If you agree, then the current behavior will make sense to you. > > > > If anything, IMO we should _reduce_ the number of unrelated events > > that trigger a call to these functions. For example, currently any > > command that reads from the minibuffer will trigger it, because when > > read-from-minibuffer exits, it restores the window configuration by > > calling set-window-configuration, which is documented to trigger these > > functions. That just doesn't make any sense to me, since most reads > > from the minibuffer don't resize any windows! > > and in a later post you said > > > I'd say, don't set the "size changed" flag unless the size really > > changed. > > and now it seems that you think that a similar argument does not apply > when running 'window-configuration-change-hook'. All true and agreed, but it doesn't contradict my main point. We could (and do) try to be as accurate as possible, but there are limits to that that cannot be easily lifted, not without some serious redesign. > I'd still need to see a hypothetical example where the same redisplay > cycle would run 'window-size-change-functions' functions twice when no > sizes actually changed. We have better things to do with our free time than discuss hypothetical examples.