Subject: Re: bug#32672: 27.0.50; image resize on window resizing

From: martin rudalics <[email-masked]>
Date: Wed, 26 Sep 2018 10:51:09 +0200

> 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 . #<buffer *scratch*>) rather

 >    (selected) - the window was selected

Yes.  But this would be stored on a per frame basis.

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

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 . #<marker at 146 in *scratch*>)

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