From: Eli Zaretskii <eliz@gnu.org>
To: martin rudalics <rudalics@gmx.at>
Cc: pipcet@gmail.com, 21333@debbugs.gnu.org
Subject: bug#21333: 25.0.50; window-size-change-functions not called after mini-window resize
Date: Tue, 25 Aug 2015 18:12:39 +0300 [thread overview]
Message-ID: <83oahvfllk.fsf@gnu.org> (raw)
In-Reply-To: <55DC185A.4080101@gmx.at>
> Date: Tue, 25 Aug 2015 09:25:14 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 21333@debbugs.gnu.org
>
> > But the coordinates of the text that stays on screen don't change in
> > such a resize. Some text is obscured, but what's left doesn't move.
> > So I see no problem here.
>
> I'm not sure what you mean here: When the minibuffer resizes and point
> is near the bottom of the window above, the window above will scroll and
> stick to the new window start position even after the minibuffer gets
> sized back. When the window above the minibuffer is a one line window
> or fixed-size, the window above that window will be subject to those
> changes.
In these two cases, yes. In all the others (which are vast majority),
no.
And I'm still not sure I understand the relevance. How exactly
knowing about the automatic resize will help with coordinates in this
case? If the Lisp program recomputes coordinates inside the hook, it
will get the same results in most cases (when point is not in the
obscured lines). 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?
> > No, it's not. It's the same issue: this hook is already called in
> > situations where it shouldn't have been, and thus imposes on the
> > programmers who use it complex ways of deciding whether there was or
> > wasn't a change they should care about. You suggest to add one more
> > situation in that class, something that most application that define
> > this hook shouldn't and don't care. It's the complexity that worries
> > me.
>
> You mean when ‘set-window-configuration’ doesn't change the size of a
> single window the hook shouldn't be called?
Yes, of course.
> Ideally it shouldn't but this is a problem similar to that of
> indenting a paragraph changing the buffer modified state although in
> reality nothing changed.
And we get regular complaints about that as well. Moreover, the
setting of the modified status by fill-paragraph is just an annoyance
that doesn't cost anyone any extra complexity, whereas the situation
with this and similar hooks costs us quite a lot in that aspect.
next prev parent reply other threads:[~2015-08-25 15:12 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 [this message]
2015-08-26 7:09 ` martin rudalics
2015-08-26 10:07 ` Pip Cet
2015-08-26 13:01 ` martin rudalics
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=83oahvfllk.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=21333@debbugs.gnu.org \
--cc=pipcet@gmail.com \
--cc=rudalics@gmx.at \
/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.