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: Mon, 24 Sep 2018 15:46:50 +0300 Message-ID: <83d0t3awqt.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> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1537793170 8622 195.159.176.226 (24 Sep 2018 12:46:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 24 Sep 2018 12:46:10 +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 Mon Sep 24 14:46:05 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 1g4QFZ-00029Y-Pn for geb-bug-gnu-emacs@m.gmane.org; Mon, 24 Sep 2018 14:46:05 +0200 Original-Received: from localhost ([::1]:45071 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g4QHg-0005cl-8v for geb-bug-gnu-emacs@m.gmane.org; Mon, 24 Sep 2018 08:48:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35921) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g4QHY-0005cg-5p for bug-gnu-emacs@gnu.org; Mon, 24 Sep 2018 08:48:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g4QHS-0000wW-D1 for bug-gnu-emacs@gnu.org; Mon, 24 Sep 2018 08:48:08 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:47209) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1g4QHS-0000wQ-7j for bug-gnu-emacs@gnu.org; Mon, 24 Sep 2018 08:48:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1g4QHS-0004C9-5n for bug-gnu-emacs@gnu.org; Mon, 24 Sep 2018 08:48: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: Mon, 24 Sep 2018 12:48: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.153779323016052 (code B ref 32672); Mon, 24 Sep 2018 12:48:02 +0000 Original-Received: (at 32672) by debbugs.gnu.org; 24 Sep 2018 12:47:10 +0000 Original-Received: from localhost ([127.0.0.1]:51466 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g4QGb-0004Aq-SB for submit@debbugs.gnu.org; Mon, 24 Sep 2018 08:47:10 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:54294) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g4QGZ-0004Aa-T8 for 32672@debbugs.gnu.org; Mon, 24 Sep 2018 08:47:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g4QGQ-0000hU-72 for 32672@debbugs.gnu.org; Mon, 24 Sep 2018 08:47:02 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34105) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g4QGP-0000hM-He; Mon, 24 Sep 2018 08:46:58 -0400 Original-Received: from [176.228.60.248] (port=3511 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1g4QGO-0007iP-OW; Mon, 24 Sep 2018 08:46:57 -0400 In-reply-to: <5BA8D7AB.5030106@gmx.at> (message from martin rudalics on Mon, 24 Sep 2018 14:25:15 +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:150600 Archived-At: > Date: Mon, 24 Sep 2018 14:25:15 +0200 > From: martin rudalics > CC: juri@linkov.net, 32672@debbugs.gnu.org > > > I agree. I think Lisp programs that use hooks provided by > > display-related code should generally expect to be called in many > > unrelated situations, and do whatever it takes by themselves to detect > > when it's "their" use case. Expectations or requests for more focused > > hooks are impractical or even not feasible to implement, because core > > code knows very little about the Lisp application which uses the hook. > > 'window-configuration-change-hook' is a great mess and is not > display-related. It is for the purposes of this discussion, since it's related to changes in what windows display which buffers and which frames show what windows. > What users really need IMO is a single hook say > 'window-state-change-functions' that we'd call in redisplay_internal > in lieu of 'window-size-change-functions'. redisplay_internal knows very little about changes in window configurations, so I predict using this new hook will be as messy as with the existing ones. > We would run it if something in the state of a frame's root window > changed (including size changes, changes of the windows' start > positions and the selected window) and additionally provide a list > of the differences in the frame's previous window state and the one > redisplay is about to use. We'd need to compute this list of changes first, and for that we will need a whole slew of new variables and flags. Currently, redisplay is built on the opposite assumption: that each operation which could potentially require redrawing some window(s) or frame(s) sets the corresponding flags of the object that needs to be redrawn, without any "explanation" of why that flag was set.