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: Wed, 26 Sep 2018 10:51:09 +0200 Message-ID: <5BAB487D.1000303@gmx.at> References: <87pnxmyjgt.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> <87a7o6ewxw.fsf@mail.linkov.net> <5BA9E378.9090105@gmx.at> <871s9hjvgn.fsf@mail.linkov.net> 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 1537951813 3899 195.159.176.226 (26 Sep 2018 08:50:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 26 Sep 2018 08:50:13 +0000 (UTC) Cc: 32672@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Sep 26 10:50: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 1g55WI-0000oW-HC for geb-bug-gnu-emacs@m.gmane.org; Wed, 26 Sep 2018 10:50:06 +0200 Original-Received: from localhost ([::1]:57111 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g55YP-0007de-3p for geb-bug-gnu-emacs@m.gmane.org; Wed, 26 Sep 2018 04:52:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58282) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g55YD-0007dT-GK for bug-gnu-emacs@gnu.org; Wed, 26 Sep 2018 04:52:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g55YA-00043V-B8 for bug-gnu-emacs@gnu.org; Wed, 26 Sep 2018 04:52:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50118) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1g55YA-00043P-75 for bug-gnu-emacs@gnu.org; Wed, 26 Sep 2018 04:52:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1g55YA-0006Ua-4K for bug-gnu-emacs@gnu.org; Wed, 26 Sep 2018 04:52:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 26 Sep 2018 08:52: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.153795188324880 (code B ref 32672); Wed, 26 Sep 2018 08:52:02 +0000 Original-Received: (at 32672) by debbugs.gnu.org; 26 Sep 2018 08:51:23 +0000 Original-Received: from localhost ([127.0.0.1]:54373 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g55XX-0006TD-Dl for submit@debbugs.gnu.org; Wed, 26 Sep 2018 04:51:23 -0400 Original-Received: from mout.gmx.net ([212.227.15.15]:53291) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g55XW-0006Sy-FM for 32672@debbugs.gnu.org; Wed, 26 Sep 2018 04:51:22 -0400 Original-Received: from [192.168.1.101] ([213.162.73.24]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MeP5b-1gP6rt0dBP-00QDX0; Wed, 26 Sep 2018 10:51:14 +0200 In-Reply-To: <871s9hjvgn.fsf@mail.linkov.net> X-Provags-ID: V03:K1:vAbDfRJtXUr1c4lsIj2rHDo0MZ/uDAR7gPjgfTk94DEBlrG2arK T7Q/9qspQgfm3kKIUpy86SLPO+tvcH3xrJ1s70D+z5wuIbgJxR/XV5daixY86Cbt8q5kV1D Yh0VoQmKTBnL1P9yqufZI6NDIdDLf2FZiR9KmIygDma8THqymdCZnkUIausWdT9GoQI9q48 1yp6JgqQgOdq2eFd3zzFw== X-UI-Out-Filterresults: notjunk:1;V01:K0:MQefMgvRUGQ=:S9HetseMYLEDF3t3PXoXDg rbfZJSE/vGbY06hNHbbUSls8ue4GoqqDsuerze3lOY+rPFbfXl2IyFg6Fcdm5EoGlx/ySxEBV LdmEvagtpCTzoWAvzn4/SZnaot2kXymncz0E+l9w6kB39o2BZ/dNvgiD8q8NBIJqMQDcuOVBB f59vQ78qCU7jsDAkDfQv94IsrlQmPsaouWwhGQF44idKHG2lesxrK0rJBSZGgZDLjNTebMiIG +HvwA0bt8xsYa5mB2guErYTEPJNjjpB0ESkjT2woCCvT09t9vpca0xoaiTjEwC+T1r0nOfIY9 E1nKYz0JGIlOop1THrjfWI5uNyzVosaar4zd9u7FcWR70t0fZMky2hR4wmF4hnOJgfYpMmMVm te2qfbzsTVwj/OIQ6UsTAHHnGMXXW/DEb6zZRS932AuJOUxdzuv+qQSClLJlKHVuXQN2rGIBf pBZCNNOU1uscYUEj/oEST+P9wpi88aGmxy/OQsCXSJSMYjdwkDx4Mmt6rkrI/2s1W2ZgugAuM UA6fnZR0tvHLrUUnAKEJpzNNvlmOHE8Dr8qah+l7VqQTtFiEWEsmiiCHEhJmdRo0Puc7b2q5A tEWjS5dTrLE4VxHjQRqZ1qf/h1drBv+ZeUmM72OK6+rUg/G2ZMmYUduI1DPqVAV8yBsjmTpWH qDaioi4wPGLigImV8oYhxMValT7PyQJxTqCkPm9Rvr/Fu6Sq+1WmaVeqEqbq6gvaw0hj8iGIm x9bbDkJ2p5V6Z/UJh2ScvN0xbVUeTjcDDte4ekMIN3WHhETtHo9sRiRbjYXwzV0Y6wII1IMf 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:150677 Archived-At: > Your proposed window-state-change-functions would match window-state-get > very well, e.g. it could call the hook with an argument containing alist > of values that really changed, where elements of the alist could have > the same keys as in alist returned from window-state-get, Retaining the nomenclature of 'window-state-get' is part of the plan. But I'm not sure whether we want to retain all of what is recorded in a window state. > for example: > > (add-hook 'window-state-change-functions (lambda (window alist) ...) nil t) > > where 'alist' could have such keys and values of changes: > > (buffer "*scratch*") - means the buffer was switched in the window (buffer . #) rather > (selected) - the window was selected Yes. But this would be stored on a per frame basis. > (start . #) - the same meaning as for > window-scroll-functions > > (pixel-width . 672) (pixel-height . 557) - the same meaning as for > window-size-change-functions Yes. And maybe the body size in pixels as well. > maybe also include > > (pixel-width-before-size-change . 672) > (pixel-height-before-size-change . 557) > > with the same meaning as window-pixel-width-before-size-change > and window-pixel-height-before-size-change > > or with shorter names > > (prev-pixel-width . 672) > (prev-pixel-height . 557) > > then it makes sense to add also > > (prev-buffer "*scratch*") > > (prev-start . #) That's one way to do that. I'm not yet sure whether there's a need for a function like 'window-prev-buffer' getting me the buffer shown the last time redisplay called 'window-state-change-functions'. If not, we could encapsulate all information for the user in the alist as you propose. > Or maybe simpler to call the hook with two arguments > containing the whole state data structures: > > (add-hook 'window-state-change-functions (lambda (window prev-state next-state) ...)) > > but then it's difficult for its consumer to find the differences. That would be considerably simpler to implement. martin