bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#32672: 27.0.50; image resize on window resizing


From: Juri Linkov
Subject: bug#32672: 27.0.50; image resize on window resizing
Date: Tue, 25 Sep 2018 22:24:16 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu)

>> 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 via email to

[Prev in Thread] Current Thread [Next in Thread]