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: Mon, 24 Sep 2018 15:46:50 +0300	[thread overview]
Message-ID: <83d0t3awqt.fsf@gnu.org> (raw)
In-Reply-To: <5BA8D7AB.5030106@gmx.at> (message from martin rudalics on Mon, 24 Sep 2018 14:25:15 +0200)

> Date: Mon, 24 Sep 2018 14:25:15 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: juri@linkov.net, 32672@debbugs.gnu.org
> 
>  > I agree.  I think Lisp programs that use hooks provided by
>  > display-related code should generally expect to be called in many
>  > unrelated situations, and do whatever it takes by themselves to detect
>  > when it's "their" use case.  Expectations or requests for more focused
>  > hooks are impractical or even not feasible to implement, because core
>  > code knows very little about the Lisp application which uses the hook.
> 
> 'window-configuration-change-hook' is a great mess and is not
> display-related.

It is for the purposes of this discussion, since it's related to
changes in what windows display which buffers and which frames show
what windows.

> What users really need IMO is a single hook say
> 'window-state-change-functions' that we'd call in redisplay_internal
> in lieu of 'window-size-change-functions'.

redisplay_internal knows very little about changes in window
configurations, so I predict using this new hook will be as messy as
with the existing ones.

> We would run it if something in the state of a frame's root window
> changed (including size changes, changes of the windows' start
> positions and the selected window) and additionally provide a list
> of the differences in the frame's previous window state and the one
> redisplay is about to use.

We'd need to compute this list of changes first, and for that we will
need a whole slew of new variables and flags.  Currently, redisplay is
built on the opposite assumption: that each operation which could
potentially require redrawing some window(s) or frame(s) sets the
corresponding flags of the object that needs to be redrawn, without
any "explanation" of why that flag was set.





  reply	other threads:[~2018-09-24 12:46 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 [this message]
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
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=83d0t3awqt.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).