From: Eli Zaretskii <eliz@gnu.org>
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: Thu, 27 Aug 2015 21:35:10 +0300 [thread overview]
Message-ID: <8337z460m9.fsf@gnu.org> (raw)
In-Reply-To: <CAOqdjBe53EXC3E53c4VwVvXE8m-yXyQHnWGrXXWpCcUdcDmM1g@mail.gmail.com>
> Date: Thu, 27 Aug 2015 17:05:35 +0000
> From: Pip Cet <pipcet@gmail.com>
> Cc: martin rudalics <rudalics@gmx.at>, 21333@debbugs.gnu.org
>
> > Since mini-window resizing can persistently
> > change the end position of the first of these windows
>
> Any command that clears the echo area will resize it back, AFAIK. So
> it's not persistent.
>
>
> That's not what I'm seeing here. When I run:
>
> (progn
> (run-with-timer 2 nil (lambda () (message "hi")))
> (run-with-timer 3 nil (lambda () (message "")))
> (read-from-minibuffer (make-string 3000 ?*)))
>
> The minibuffer resizes once, when the read-from-minibuffer prompt makes it grow
> to its maximal size; it then stays at that size as the short message is being
> displayed, then restores the long minibuffer prompt without changing size again
> when the echo area is cleared.
That's a different situation, quite bizarre btw.
Just run normal code, like only the message above, then move the
cursor, and you will see the echo area shrink back. That's the normal
use case.
> > OT1H we do care about point being visible when its window is partially
> > obscured by the mini-window and deliberately scroll the window in that
> > case. OTOH we'd say that `follow-mode' should not care about keeping
> > its text coherent in that case. Is that fair?
>
> Yes. In that situation, the user most probably reads the mini-window
> text anyway, and if not, then she reads the text at point. The
> probability that she is reading the text that will be scrolled out of
> view as result of the mini-window resize is IMO minuscule.
>
> So if, for whatever reason, I have a timer function that displays a two-line
> message once a second (so the echo area never goes back to its single-line
> state), my follow-mode buffer will be and remain in an inconsistent state until
> I manually resize a window, when it will go back to a consistent state, but
> then if I cancel the timer (and the mini-window shrinks) it'll be in an
> inconsistent state again, and the only way out of that one is another manual
> window resize?
I'd say just don't do that, it's terribly annoying to see such display
even without the other issues.
> I think that last case is something we haven't considered yet: if I resize
> windows manually while the mini-window is enlarged, they will be in an
> inconsistent state when it goes back to normal, right?
What do you mean by "inconsistent state"?
next prev parent reply other threads:[~2015-08-27 18:35 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 [this message]
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
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=8337z460m9.fsf@gnu.org \
--to=eliz@gnu.org \
--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.