unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Juri Linkov <juri@linkov.net>
To: martin rudalics <rudalics@gmx.at>
Cc: 32672@debbugs.gnu.org
Subject: bug#32672: 27.0.50; image resize on window resizing
Date: Tue, 25 Sep 2018 22:24:16 +0300	[thread overview]
Message-ID: <871s9hjvgn.fsf@mail.linkov.net> (raw)
In-Reply-To: <5BA9E378.9090105@gmx.at> (martin rudalics's message of "Tue, 25 Sep 2018 09:27:52 +0200")

>> I think window hook calls should be consistent at least with own inner logic,
>> e.g. as the semantics of the window-size-change-functions hook name suggests
>> it should be called when the window size is not the same as was before,
>> window-configuration-change-hook is called when the result of window-state-get
>> is not the same as it was before, etc.
>
> Tying 'window-configuration-change-hook' to 'window-state-get' would
> be considerably more than we do now or what I'd propose.  We probably
> shouldn't care about a specific window's scroll bars or margins there.

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, 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

  (selected) - the window was selected

  (start . #<marker at 146 in *scratch*>)  - the same meaning as for
                                             window-scroll-functions

  (pixel-width . 672) (pixel-height . 557) - the same meaning as for
                                             window-size-change-functions
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 . #<marker at 146 in *scratch*>)

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.





  reply	other threads:[~2018-09-25 19:24 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-09 15:54 bug#32672: 27.0.50; image resize on window resizing Juri Linkov
2018-09-11 23:53 ` Juri Linkov
2018-09-12  6:33   ` martin rudalics
2018-09-12 23:18     ` Juri Linkov
2018-09-13  7:46       ` martin rudalics
2018-09-13 23:20         ` Juri Linkov
2018-09-14  8:33           ` martin rudalics
2018-09-15 23:35             ` Juri Linkov
2018-09-16  9:10               ` martin rudalics
2018-09-16 23:49                 ` Juri Linkov
2018-09-17  6:46                   ` martin rudalics
2018-09-17 22:35                     ` Juri Linkov
2018-09-19  8:22                       ` martin rudalics
2018-09-19 23:15                         ` Juri Linkov
2018-09-20  7:34                           ` martin rudalics
2018-09-20 23:15                             ` Juri Linkov
2018-09-21  6:34                               ` martin rudalics
2018-09-22 22:15                                 ` Juri Linkov
2018-09-23  8:26                                   ` martin rudalics
2018-09-23 20:39                                     ` Juri Linkov
2018-09-24  8:22                                       ` martin rudalics
2018-09-24  8:35                                         ` Eli Zaretskii
2018-09-24 12:25                                           ` martin rudalics
2018-09-24 12:46                                             ` Eli Zaretskii
2018-09-24 17:37                                               ` martin rudalics
2018-09-24 17:53                                                 ` Eli Zaretskii
2018-09-25  7:26                                                   ` martin rudalics
2018-09-25  9:19                                                     ` Eli Zaretskii
2018-09-25 17:56                                                       ` martin rudalics
2018-09-25 18:31                                                         ` Eli Zaretskii
2018-09-24 18:38                                           ` Juri Linkov
2018-09-24 19:31                                             ` Eli Zaretskii
2018-09-25  7:27                                             ` martin rudalics
2018-09-25 19:24                                               ` Juri Linkov [this message]
2018-09-26  8:51                                                 ` martin rudalics
2018-10-27 19:38                                                   ` Juri Linkov
2018-10-28  8:59                                                     ` martin rudalics
2018-09-24 18:31                                         ` Juri Linkov
2018-09-25  7:27                                           ` martin rudalics
2018-12-26 23:42 ` Juri Linkov
2018-12-27  9:36   ` martin rudalics
2018-12-27 21:41     ` Juri Linkov
2018-12-28  8:34       ` martin rudalics
2018-12-27 15:48   ` Eli Zaretskii
2018-12-27 20:58     ` Juri Linkov
2018-12-28  4:51       ` Eli Zaretskii
2019-09-26 13:27   ` Lars Ingebrigtsen
2019-11-27 21:53     ` Juri Linkov
2019-11-28  9:20       ` martin rudalics
2019-11-28 22:50         ` Juri Linkov
2019-11-29  9:24           ` martin rudalics

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871s9hjvgn.fsf@mail.linkov.net \
    --to=juri@linkov.net \
    --cc=32672@debbugs.gnu.org \
    --cc=rudalics@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).