GNU bug report logs - #32672
27.0.50; image resize on window resizing

Previous Next

Full log

Message #113 received at 32672 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 32672 <at> debbugs.gnu.org
Subject: Re: 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.