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: martin rudalics
Subject: bug#32672: 27.0.50; image resize on window resizing
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





reply via email to

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