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: 55412@debbugs.gnu.org, acm@muc.de, tanzer@swing.co.at
Subject: bug#55412: 28.1; In Emacs 28.1, using ':eval' in 'frame-title-format' doesn't work properly
Date: Fri, 20 May 2022 13:58:45 +0300	[thread overview]
Message-ID: <83k0agbhcq.fsf@gnu.org> (raw)
In-Reply-To: <408f7b88-2000-bd10-bd9d-4e06018e8ff0@gmx.at> (message from martin rudalics on Fri, 20 May 2022 10:23:17 +0200)

> Date: Fri, 20 May 2022 10:23:17 +0200
> Cc: 55412@debbugs.gnu.org, tanzer@swing.co.at
> From: martin rudalics <rudalics@gmx.at>
> 
>  > It would be good to have some of these explanations in comments there.
> 
> I understand that we want a quick solution for the present bug so it can
> be included in Emacs 28.2.  But I still don't understand why nobody even
> cared to try the patch I sent earlier.

I don't think I understand what patch that is, but we could install
different solutions on master and the release branches.

In general, I prefer the old code to a new one, because the old code
by definition keeps old behavior, and thus runs lower risks of
breaking something.  But I won't object installing what is deemed a
better solution on master, even though it is riskier.

> With the current code, whenever there are at least two frames
> present, 'gui_consider_frame_title' calls via Fselect_window among
> others
> 
> redisplay_other_windows
> 
> Fredirect_frame_focus
> 
> resize_mini_window
> 
> move_minibuffers_onto_frame
> 
> and sets
> 
> last_nonminibuf_frame
> 
> internal_last_event_frame
> 
> Has anyone ever tried to understand the implications of all these?

Why would we need to do that?  This code was there for many years, so
its effects are by now a de-facto standard behavior of Emacs.  We
don't have human power and resources to revisit those decisions unless
someone submits a bug report, or unless some deep refactoring or
reimplementation of the code is taking place.

> When trying to fix Bug#32777 I spent some time investigating these
> issues but never found out why on earth we should call routines like
> 'select-frame' and 'select-window' from redisplay.

Well, now we know at least one reason: so that referencing
frame-parameters would what Lisp programs expect.





  reply	other threads:[~2022-05-20 10:58 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-14 15:45 bug#55412: 28.1; In Emacs 28.1, using ':eval' in 'frame-title-format' doesn't work properly Christian Tanzer
2022-05-14 16:58 ` Eli Zaretskii
2022-05-14 17:07   ` Eli Zaretskii
2022-05-15  9:48   ` Alan Mackenzie
2022-05-15 10:16     ` Eli Zaretskii
2022-05-16 20:52   ` Alan Mackenzie
2022-05-17 13:25     ` Eli Zaretskii
2022-05-18  7:19     ` martin rudalics
2022-05-18 11:35       ` Eli Zaretskii
2022-05-18 15:01         ` martin rudalics
2022-05-18 15:12           ` Alan Mackenzie
2022-05-18 15:49           ` Alan Mackenzie
2022-05-18 16:03             ` Eli Zaretskii
2022-05-18 16:38               ` Alan Mackenzie
2022-05-18 16:51                 ` Eli Zaretskii
2022-05-20  8:23                   ` martin rudalics
2022-05-20 10:58                     ` Eli Zaretskii [this message]
2022-05-21  8:32                       ` martin rudalics
2022-05-21  8:35                         ` Eli Zaretskii
2022-05-20 11:33                     ` Alan Mackenzie
2022-05-20 12:10                       ` Eli Zaretskii
2022-05-21  8:32                       ` martin rudalics
2022-05-21  8:59                         ` Eli Zaretskii
2022-05-19  7:18             ` martin rudalics
2022-05-20 20:39   ` Alan Mackenzie
2022-05-21 11:25     ` tanzer--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-05-21 12:35       ` Eli Zaretskii
2022-05-22 17:34       ` Alan Mackenzie
2022-05-15  9:28 ` 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=83k0agbhcq.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=55412@debbugs.gnu.org \
    --cc=acm@muc.de \
    --cc=rudalics@gmx.at \
    --cc=tanzer@swing.co.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).