From: martin rudalics <rudalics@gmx.at>
To: Pip Cet <pipcet@gmail.com>
Cc: 21333@debbugs.gnu.org
Subject: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize
Date: Wed, 26 Aug 2015 15:01:22 +0200 [thread overview]
Message-ID: <55DDB8A2.8020606@gmx.at> (raw)
In-Reply-To: <CAOqdjBdPoH3EHRrjZ1-zguZMP=w7W8_biOM6qa_bLy0pAwMKbw@mail.gmail.com>
>>> So an alternative that doesn't need any hook is
>>> simply to recompute the coordinates every time they are needed. It's
>>> not like this calculation is expensive, is it?
>>
>> Correct.
>
> I disagree, if I understand correctly.
My "correct" referred to Eli's "It's not like this calculation is
expensive, is it?". I suppose we all agree on that.
> The coordinates might be passed
> to another program, for example, and then we simply don't know when
> that program decides to use them, so we still need a way to update our
> (and its) idea of what the window size and position is, in my opinion.
I don't understand you here. IIUC Eli means that any application can
store the old coordinates somewhere and easily compare them to the
current ones in order to detect whether window sizes have changed.
Even simpler: We could store the sizes in the window structure. This
way prepare_menu_bars would simply walk the window tree of each frame to
detect whether the size of any window has changed, call the functions on
‘window-size-change-functions’ and afterwards (better when redisplay
completed) store the current size values into the old ones. The
functions on the hook, OTOH, could check for each window individually
whether and how its size changed. The advantage of this approach is
that we never accumulate any fake size changes.
>> So ‘window-size-change-functions’ is dispensable.
>
> Iff we keep/fix pre-redisplay-function, I agree. I had, wrongly,
> assumed that pre-redisplay-function is run many times per redisplay
> call, but that appears to be incorrect. The huge majority of
> redisplays call it just once, and that makes the overhead negligible.
We can declare ‘window-size-change-functions’ obsolete and suggest to
use ‘pre-redisplay-function’ instead. Still we'd have to support it for
quite some time.
> So what's the way forward, assuming my paperwork ever gets here?
> - document window-size-change-functions aren't called for mini-window resizes
... and maybe neither when the menu or tool bar wrap.
Yes (if we decide to not change anything else).
> - document window-configuration-change-hook isn't called for
> mini-window resizes
No (because we nowhere say that `window-configuration-change-hook' is
called for resize operations).
> - document set-window-configuration doesn't call
> window-size-change-functions if nothing changed
No (because IIRC we never document fixed bugs).
> - fix set_window_configuration not to set the window size change flag
> unless there was an actual size change
Unless we decide to move that check to prepare_menu_bars as I sketched
above.
> - wishlist item: call pre-redisplay-function between
> grow/shrink_mini_window and the actual X repaint, rather than before.
Are you sure? If prepare_menu_bars is called before auto-resizing the
minibuffer window, then ‘window-size-change-functions’ wouldn't catch
those auto-resizes either.
> - mark window-size-change-functions as obsolete and see whether
> anyone complains?
This will happen if we don't provide a good subsitute.
> + if (w->pixel_left != XFASTINT (p->pixel_left) ||
> + w->pixel_top != XFASTINT (p->pixel_top) ||
> + w->pixel_width != XFASTINT (p->pixel_width) ||
> + w->pixel_height != XFASTINT (p->pixel_height))
You still didn't explain why you find it necessary to compare the
pixel_left and pixel_top values.
martin
next prev parent reply other threads:[~2015-08-26 13:01 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-23 22:06 bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize Pip Cet
2015-08-24 8:18 ` martin rudalics
2015-08-24 11:08 ` Pip Cet
2015-08-24 12:41 ` martin rudalics
2015-08-24 14:35 ` Eli Zaretskii
2015-08-24 18:06 ` martin rudalics
2015-08-24 18:30 ` Eli Zaretskii
2015-08-25 7:25 ` martin rudalics
2015-08-25 10:34 ` Pip Cet
2015-08-25 15:19 ` Eli Zaretskii
2015-08-26 7:08 ` martin rudalics
2015-08-25 15:11 ` Eli Zaretskii
2015-08-26 7:09 ` martin rudalics
2015-08-26 15:29 ` Eli Zaretskii
2015-08-27 7:57 ` martin rudalics
2015-08-27 15:29 ` Eli Zaretskii
2015-08-27 17:05 ` Pip Cet
2015-08-27 17:59 ` martin rudalics
2015-08-27 18:04 ` Pip Cet
2015-08-28 8:03 ` martin rudalics
2015-08-28 8:19 ` Pip Cet
2015-08-28 8:45 ` Pip Cet
2015-08-27 18:35 ` Eli Zaretskii
2015-08-27 17:58 ` martin rudalics
2015-08-24 18:13 ` Pip Cet
2015-08-24 19:03 ` Eli Zaretskii
2015-08-25 7:25 ` martin rudalics
2015-08-25 15:12 ` Eli Zaretskii
2015-08-26 7:09 ` martin rudalics
2015-08-26 10:07 ` Pip Cet
2015-08-26 13:01 ` martin rudalics [this message]
2015-08-26 16:00 ` Pip Cet
2015-08-27 7:59 ` martin rudalics
2015-08-27 15:25 ` Eli Zaretskii
2015-08-27 16:35 ` Pip Cet
2015-08-27 17:59 ` martin rudalics
2015-08-27 18:57 ` Eli Zaretskii
2015-08-27 20:49 ` Pip Cet
2015-08-28 10:02 ` Eli Zaretskii
2015-08-28 12:34 ` Pip Cet
2015-08-28 13:13 ` Eli Zaretskii
2015-08-28 13:26 ` Pip Cet
2015-08-26 15:36 ` Eli Zaretskii
2015-08-27 7:58 ` martin rudalics
2015-08-27 15:24 ` Eli Zaretskii
2015-08-27 17:58 ` martin rudalics
2015-08-27 18:39 ` Eli Zaretskii
2015-08-27 19:00 ` Eli Zaretskii
2015-08-28 8:04 ` martin rudalics
2015-08-28 8:47 ` Eli Zaretskii
2015-08-28 10:51 ` martin rudalics
2015-08-28 12:46 ` Eli Zaretskii
2015-08-28 13:05 ` martin rudalics
2015-08-26 15:32 ` Eli Zaretskii
2015-08-27 7:57 ` martin rudalics
2016-02-22 12:59 ` Fix `window-configuration-change-hook' and `window-size-change-functions' martin rudalics
2016-02-23 11:31 ` 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55DDB8A2.8020606@gmx.at \
--to=rudalics@gmx.at \
--cc=21333@debbugs.gnu.org \
--cc=pipcet@gmail.com \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.