unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Markus Triska <triska@metalevel.at>
To: martin rudalics <rudalics@gmx.at>
Cc: 52666@debbugs.gnu.org
Subject: bug#52666: 27.0.50; Unexpected mode line flickering when creating frames
Date: Tue, 21 Dec 2021 21:44:43 +0100	[thread overview]
Message-ID: <87o859vgas.fsf@metalevel.at> (raw)
In-Reply-To: <6faae86d-b1ef-57b4-e5d8-298c7777be24@gmx.at> (martin rudalics's message of "Tue, 21 Dec 2021 11:32:53 +0100")

martin rudalics <rudalics@gmx.at> writes:

> I later found out that with my GTK-3 build the child frame never became
> visible with your original recipe when I moved the mouse into the area
> reserved for it.  Maybe this is related to my focus follows mouse
> settings maybe it's something else.

I also noticed this: When the mouse is in the area where the new frame
arises, then the new frame is selected on all platforms I tried. I have
set focus-follows-mouse to nil (the default). Ideally, I would like the
existing frame to reliably retain the focus, and the new frame to not be
selected when it is created. Is there any way to reliably ensure this?

> corner of the parent's native frame.  Since the size of the child frame
> is by default that of its parent, the child frame will thus draw over
> the entire area of the parent frame (including mode line and scroll

I think this is the part that can be counterintuitive, since the Elisp
documentation states:

    39.2 Forcing Redisplay
    ======================

    Emacs normally tries to redisplay the screen whenever it waits for
    input.

In the example that exhibits the flickering, there is no waiting for
input between the creation of the frame and the change of its width and
height. Therefore, it is unexpected that the frame is drawn over the
entire area of the parent frame. I expected it to be drawn only for the
area it is configured, when Emacs waits for input.

Thank you and all the best,
Markus





  reply	other threads:[~2021-12-21 20:44 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-19 20:42 bug#52666: 27.0.50; Unexpected mode line flickering when creating frames Markus Triska
2021-12-20  9:18 ` martin rudalics
2021-12-20 15:11 ` Eli Zaretskii
2021-12-20 17:21   ` martin rudalics
2021-12-20 18:23     ` Markus Triska
2021-12-20 18:30       ` martin rudalics
2021-12-20 18:41         ` Markus Triska
2021-12-21 10:32           ` martin rudalics
2021-12-21 20:44             ` Markus Triska [this message]
2021-12-22  9:22               ` martin rudalics
2021-12-22 13:37                 ` Eli Zaretskii
2021-12-22 16:33                 ` Markus Triska
2021-12-23 14:46                   ` martin rudalics
2021-12-23 16:23                     ` Markus Triska

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=87o859vgas.fsf@metalevel.at \
    --to=triska@metalevel.at \
    --cc=52666@debbugs.gnu.org \
    --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).