From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#32672: 27.0.50; image resize on window resizing Date: Tue, 25 Sep 2018 19:56:09 +0200 Message-ID: <5BAA76B9.8090007@gmx.at> 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1537898141 19367 195.159.176.226 (25 Sep 2018 17:55:41 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 25 Sep 2018 17:55:41 +0000 (UTC) Cc: 32672@debbugs.gnu.org, juri@linkov.net To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Sep 25 19:55:36 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 1g4rYe-0004vD-3v for geb-bug-gnu-emacs@m.gmane.org; Tue, 25 Sep 2018 19:55:36 +0200 Original-Received: from localhost ([::1]:54618 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g4rak-0003zv-Ob for geb-bug-gnu-emacs@m.gmane.org; Tue, 25 Sep 2018 13:57:46 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51207) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g4ra7-0003eE-T0 for bug-gnu-emacs@gnu.org; Tue, 25 Sep 2018 13:57:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g4ra3-0002bR-OI for bug-gnu-emacs@gnu.org; Tue, 25 Sep 2018 13:57:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:49738) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1g4ra3-0002ak-JN for bug-gnu-emacs@gnu.org; Tue, 25 Sep 2018 13:57:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1g4ra2-0006rl-7Z for bug-gnu-emacs@gnu.org; Tue, 25 Sep 2018 13:57:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 25 Sep 2018 17:57: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.153789818826340 (code B ref 32672); Tue, 25 Sep 2018 17:57:02 +0000 Original-Received: (at 32672) by debbugs.gnu.org; 25 Sep 2018 17:56:28 +0000 Original-Received: from localhost ([127.0.0.1]:53993 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g4rZU-0006qm-Jk for submit@debbugs.gnu.org; Tue, 25 Sep 2018 13:56:28 -0400 Original-Received: from mout.gmx.net ([212.227.15.19]:54467) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g4rZS-0006qZ-Ts for 32672@debbugs.gnu.org; Tue, 25 Sep 2018 13:56:27 -0400 Original-Received: from [192.168.1.100] ([213.162.73.255]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M5Lmp-1fqLKZ4Aed-00zYK8; Tue, 25 Sep 2018 19:56:17 +0200 In-Reply-To: <837eja9boy.fsf@gnu.org> X-Provags-ID: V03:K1:jQc4VCUdx4iiIG88pbOeB4eGhXE4ozw1MVaGEdHBzBeMkJh5K3Z q/FngrezuFBdjOzNlGXhyalk7ardx0FaA0lCelxbZEOXNSReWD7/REh6JS6SbG194nIG6pK 5H5yKfZ95236dJ7LpZmFFKJBSx3xAtfTdHmTaP+6GUGNMFigTDARwU1uOFoiXJPAZLGK8oZ JUIEeQVj/FBLK6xF3HDew== X-UI-Out-Filterresults: notjunk:1;V01:K0:6y2L+3lBxNk=:TlS57s4lyWyBsFP3J7RE5w NkXk7WkH1Nujx6qrOmFOc8SCez/DuftSsEU4avcIeWiABAQ4ES8vZUJA6EcEZ9rwRyT9zU1N9 QZPQcXUpfVQA/3WtQSsDyFcynIlvdErlVuBrrrE+q+9DylSlhLn6UEB1MkT+3SKmMN33V5gvR 86mh2ECnRUg6AEznp3smJjPlnwskVmIUjYQSV6U8qRltuNFzXBbrUJkfEJYYyn0oM2OO2Uvyf HLEyjSyp5F4+Zy/UvdRFLQ0xpqBoXo5lG6EZeM3RvORO4gzsRL+7swJl7unkFp6jcwoQIWqSH HwQeWUTy40bvyQzpKeQG5IG3YjLtPH9DRJ448XgUH9CBzRMj2B3zOdJUJNNI6C07dEAlBwUqY qFSnYmz83uJGHFqARMZ3QjyBeqsb4mcRcpNA/9hQmh8TZx8+p9WZCN2CyCociHP+Mt+5gIbtC fm6txVCPbMNssuherqArKeiWMfXygTe9uf/YrfJiGGrmLkpaL5qsWv3S3u3+JQS29tkd2vzf9 XH0KTbBKb2yfp+bR2+tYAAehBS5qDZ9ICc54qQqcDQ0v86CsZzZjI8NO9dXHAWx4aEM9jpIxd gJ6+KZBTi2Wvj5KOFWtZMN/kEepj/h5V0RT5lLQjUrmFsv0A8ei95r7KeY3tSUJJ493jCS9Ic 7Ft4aCIePFX4iBLWy1VVFvoMl4R5QVf0hQcznFhFQz2zojir5iGgvY39c0iaE44Vf4AVJKB4r 17u/Nm8fecikEaAror1c0NsbCreUcgieW0wr+myT51r/SkQoQBIKxU1IzPQw8htj0VUQ8seM 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:150653 Archived-At: >> I'm not sure what you mean with "Those functions". > > I mean window-state-change-functions, what else? That would be a hook and would indeed have to do the work. But why the plural? > We are talking about hypothetical function(s), so it may well be that > there's some misunderstanding. My point is that accurate recording of > window-size changes is hard, because the various variables used for > that might be outdated (e.g., due top a redisplay cycle that didn't > complete). Also, redisplay_internal, which calls those functions, > will sometimes call them more than once in a redisplay cycle (see the > 'retry' label and code that jumps back to it). > > 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'. 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. martin