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: 46827@debbugs.gnu.org, rpluim@gmail.com, stephen.berman@gmx.net
Subject: bug#46827: Broken initial size of GTK3 frame
Date: Sat, 06 Mar 2021 13:15:29 +0200	[thread overview]
Message-ID: <83ft18wn1q.fsf@gnu.org> (raw)
In-Reply-To: <735366e4-389c-1c71-438d-6d928de02e44@gmx.at> (message from martin rudalics on Wed, 3 Mar 2021 10:40:04 +0100)

> Cc: stephen.berman@gmx.net, rpluim@gmail.com, 46827@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Wed, 3 Mar 2021 10:40:04 +0100
> 
>  >> 	  if (!must_finish)
>  >> 	    {
>  >> 	      do_pending_window_change (true);
>  >> 	      /* If selected_window changed, redisplay again.  */
>  >> 	      if (WINDOWP (selected_window)
>  >> 		  && (w = XWINDOW (selected_window)) != sw)
>  >> 		goto retry;
>  >>
>  >> not check for windows_or_buffers_changed too just as we do after the
>  >> third do_pending_window_change call?
>  >
>  > Because going to 'retry' will eventually make that check again.  Or
>  > maybe I don't understand what exactly are you asking here?
> 
> The check above doesn't care about windows_or_buffers_changed.  The last
> one in redisplay_internal does:
> 
>    /* Change frame size now if a change is pending.  */
>    do_pending_window_change (true);
> 
>    /* If we just did a pending size change, or have additional
>       visible frames, or selected_window changed, redisplay again.  */
>    if ((windows_or_buffers_changed && !pending)
>        || (WINDOWP (selected_window)
> 	  && (w = XWINDOW (selected_window)) != sw))
>      goto retry;
> 
> So if in the (!must_finish) guarded check windows_or_buffers_changed was
> set but the selected window remained unchanged, we don't go to retry.

I still don't see the problem, because that last check you show above
will catch that, right?

>  >> But then I don't understand why we
>  >> check for windows_or_buffers_changed at all.  adjust_frame_size doesn't
>  >> set that IIUC but it does garbage the frame - why don't we check that in
>  >> redisplay_internal?
>  >
>  > Sorry, I don't understand the question.  We _are_ talking about
>  > redisplay_internal, right? and redisplay_internal does check
>  > windows_or_buffers_changed, right? so what do you mean by "why don't
>  > we check that in redisplay_internal"? and what is "that" in this case?
> 
> I meant to ask why we don't check the f->garbaged flag of the frame
> instead of windows_or_buffers_changed.  do_pending_window_change to my
> knowledge does not set windows_or_buffers_changed but sets the garbaged
> flag.

SET_FRAME_GARBAGED also causes windows_or_buffers_changed to be set.





  reply	other threads:[~2021-03-06 11:15 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-28  9:31 bug#46827: Broken initial size of GTK3 frame martin rudalics
2021-02-28 18:09 ` Eli Zaretskii
2021-03-01  8:32   ` martin rudalics
2021-03-01  9:46     ` martin rudalics
2021-03-01  8:31 ` martin rudalics
2021-03-01 10:15   ` Robert Pluim
2021-03-01 12:38     ` martin rudalics
2021-03-01 13:30       ` Robert Pluim
2021-03-01 13:53         ` Robert Pluim
2021-03-01 18:03           ` martin rudalics
2021-03-01 18:23             ` Robert Pluim
2021-03-01 18:32               ` Robert Pluim
2021-03-01 19:05                 ` martin rudalics
2021-03-01 19:04               ` martin rudalics
2021-03-01 20:00                 ` Robert Pluim
2021-03-02  8:24                   ` martin rudalics
2021-03-01 19:49               ` Stephen Berman
2021-03-02  8:24                 ` martin rudalics
2021-03-02  9:07                   ` martin rudalics
2021-03-02 10:11                     ` Robert Pluim
2021-03-02 14:11                     ` Eli Zaretskii
2021-03-02 16:07                       ` martin rudalics
2021-03-02 16:35                         ` Eli Zaretskii
2021-03-03  8:48                           ` martin rudalics
2021-03-03  9:05                             ` Eli Zaretskii
2021-03-03  9:40                               ` martin rudalics
2021-03-06 11:15                                 ` Eli Zaretskii [this message]
2021-03-06 19:28                                   ` martin rudalics
2021-03-02  9:17                   ` Stephen Berman
2021-03-02 10:02                     ` martin rudalics
2021-03-01 18:03         ` martin rudalics
2021-03-01 14:07   ` Eli Zaretskii
2021-03-01 18:04     ` martin rudalics
2021-04-27  8:23 ` martin rudalics
2021-04-29 16:13   ` Juri Linkov
2021-04-29 17:06     ` martin rudalics
2021-04-29 23:06       ` Juri Linkov
2021-04-30  6:26         ` martin rudalics
2021-04-30 17:12           ` Juri Linkov
2021-04-30 17:37             ` martin rudalics
2021-05-01 20:06               ` Juri Linkov
2021-05-02  7:38                 ` martin rudalics
2021-05-02 20:46                   ` Juri Linkov
2021-05-03  7:49                     ` martin rudalics
2021-05-03 16:40                       ` Juri Linkov
2021-05-03 16:51                       ` martin rudalics
2021-05-03 17:01                         ` Juri Linkov
2021-05-03 17:32                           ` martin rudalics
2021-05-04  8:07                             ` martin rudalics
2021-05-04 21:33                               ` Juri Linkov
2021-05-05  7:25                                 ` martin rudalics
2021-05-05 20:34                                   ` Juri Linkov
2021-05-06  7:45                                     ` martin rudalics
2021-05-07 16:52                                       ` Juri Linkov
2021-05-10  8:23                                         ` martin rudalics
2021-05-10 20:39                                           ` Juri Linkov
2021-05-11  8:44                                             ` martin rudalics
2021-05-11 17:49                                               ` Juri Linkov
2021-05-12  8:47                                                 ` martin rudalics
2021-05-12 17:28                                                   ` Juri Linkov
2021-05-13  7:54                                                     ` martin rudalics
2021-05-13 16:24                                                       ` Juri Linkov
2021-05-14  7:08                                                         ` martin rudalics
2021-05-14 18:10                                                           ` Juri Linkov
2021-05-15  7:56                                                             ` 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=83ft18wn1q.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=46827@debbugs.gnu.org \
    --cc=rpluim@gmail.com \
    --cc=rudalics@gmx.at \
    --cc=stephen.berman@gmx.net \
    /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).