unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: martin rudalics <rudalics@gmx.at>
Cc: 32672@debbugs.gnu.org, juri@linkov.net
Subject: bug#32672: 27.0.50; image resize on window resizing
Date: Tue, 25 Sep 2018 21:31:10 +0300	[thread overview]
Message-ID: <83sh1x8m4x.fsf@gnu.org> (raw)
In-Reply-To: <5BAA76B9.8090007@gmx.at> (message from martin rudalics on Tue, 25 Sep 2018 19:56:09 +0200)

> Date: Tue, 25 Sep 2018 19:56:09 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: juri@linkov.net, 32672@debbugs.gnu.org
> 
>  > Bottom line is what I said up-thread: Lisp programs cannot expect
>  > those hook calls to be too accurate and focused, they need to be
>  > prepared to handle many irrelevant calls, and they had better have
>  > their own bookkeeping regarding window dimensions etc.
> 
> 'window-size-change-functions' is not hypothetical and guards itself
> against running twice for unchanged window sizes.  I don't really
> understand what you doubt here - I rewrote it in its current form
> because you once said (when discussing Bug#21333) that
> 
>  > I believe window-size-change-functions is meant for taking notice of
>  > resizes done by the user or some Lisp code, not for automated resizes
>  > whose sole purpose is to allow some message be read in its entirety.
>  > If you agree, then the current behavior will make sense to you.
>  >
>  > If anything, IMO we should _reduce_ the number of unrelated events
>  > that trigger a call to these functions.  For example, currently any
>  > command that reads from the minibuffer will trigger it, because when
>  > read-from-minibuffer exits, it restores the window configuration by
>  > calling set-window-configuration, which is documented to trigger these
>  > functions.  That just doesn't make any sense to me, since most reads
>  > from the minibuffer don't resize any windows!
> 
> and in a later post you said
> 
>  > I'd say, don't set the "size changed" flag unless the size really
>  > changed.
> 
> and now it seems that you think that a similar argument does not apply
> when running 'window-configuration-change-hook'.

All true and agreed, but it doesn't contradict my main point.  We
could (and do) try to be as accurate as possible, but there are limits
to that that cannot be easily lifted, not without some serious
redesign.

> I'd still need to see a hypothetical example where the same redisplay
> cycle would run 'window-size-change-functions' functions twice when no
> sizes actually changed.

We have better things to do with our free time than discuss
hypothetical examples.





  reply	other threads:[~2018-09-25 18:31 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-09 15:54 bug#32672: 27.0.50; image resize on window resizing Juri Linkov
2018-09-11 23:53 ` Juri Linkov
2018-09-12  6:33   ` martin rudalics
2018-09-12 23:18     ` Juri Linkov
2018-09-13  7:46       ` martin rudalics
2018-09-13 23:20         ` Juri Linkov
2018-09-14  8:33           ` martin rudalics
2018-09-15 23:35             ` Juri Linkov
2018-09-16  9:10               ` martin rudalics
2018-09-16 23:49                 ` Juri Linkov
2018-09-17  6:46                   ` martin rudalics
2018-09-17 22:35                     ` Juri Linkov
2018-09-19  8:22                       ` martin rudalics
2018-09-19 23:15                         ` Juri Linkov
2018-09-20  7:34                           ` martin rudalics
2018-09-20 23:15                             ` Juri Linkov
2018-09-21  6:34                               ` martin rudalics
2018-09-22 22:15                                 ` Juri Linkov
2018-09-23  8:26                                   ` martin rudalics
2018-09-23 20:39                                     ` Juri Linkov
2018-09-24  8:22                                       ` martin rudalics
2018-09-24  8:35                                         ` Eli Zaretskii
2018-09-24 12:25                                           ` martin rudalics
2018-09-24 12:46                                             ` Eli Zaretskii
2018-09-24 17:37                                               ` martin rudalics
2018-09-24 17:53                                                 ` Eli Zaretskii
2018-09-25  7:26                                                   ` martin rudalics
2018-09-25  9:19                                                     ` Eli Zaretskii
2018-09-25 17:56                                                       ` martin rudalics
2018-09-25 18:31                                                         ` Eli Zaretskii [this message]
2018-09-24 18:38                                           ` Juri Linkov
2018-09-24 19:31                                             ` Eli Zaretskii
2018-09-25  7:27                                             ` martin rudalics
2018-09-25 19:24                                               ` Juri Linkov
2018-09-26  8:51                                                 ` martin rudalics
2018-10-27 19:38                                                   ` Juri Linkov
2018-10-28  8:59                                                     ` martin rudalics
2018-09-24 18:31                                         ` Juri Linkov
2018-09-25  7:27                                           ` martin rudalics
2018-12-26 23:42 ` Juri Linkov
2018-12-27  9:36   ` martin rudalics
2018-12-27 21:41     ` Juri Linkov
2018-12-28  8:34       ` martin rudalics
2018-12-27 15:48   ` Eli Zaretskii
2018-12-27 20:58     ` Juri Linkov
2018-12-28  4:51       ` Eli Zaretskii
2019-09-26 13:27   ` Lars Ingebrigtsen
2019-11-27 21:53     ` Juri Linkov
2019-11-28  9:20       ` martin rudalics
2019-11-28 22:50         ` Juri Linkov
2019-11-29  9:24           ` 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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83sh1x8m4x.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=32672@debbugs.gnu.org \
    --cc=juri@linkov.net \
    --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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).