From: martin rudalics <rudalics@gmx.at>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 13225@debbugs.gnu.org
Subject: bug#13225: 24.3.50; Non-selected window has not mode-line-inactive face
Date: Sat, 22 Dec 2012 18:42:04 +0100 [thread overview]
Message-ID: <50D5F0EC.9060303@gmx.at> (raw)
In-Reply-To: <jwvvcbukp1l.fsf-monnier+emacs@gnu.org>
> I believe we always do, especially when (potentially) running Elisp
> code, which can in turn run pretty much any code.
Who am I to object? I thought the purpose of this was that a user can,
in her mode line code, call `frame-selected-window' to check whether the
currently selected window really is the selected window (at least in a
one-frame environment). If we synchronize the frame's selected window
too, there's no way to get that any more. Not that such a kludgy
behavior seems reasonable ...
> Oh, that's what you mean. Yes, maybe we could/should just use
> select_window(_norecord) (which is not just the way
> run_window_configuration_change_hook does it,
If the function on the hook is local to the window's buffer, it does
precisely that. Which is not entirely kosher because that function will
have no idea about the really selected window but we always have the
global hook for that.
> but is more generally the
> normal way to do it). My recent change already brings display_mode_lines
> closer to what select_window does.
IIUC display_mode_lines contains the only Lisp running code where the
selected window does not necessarily equal the selected window of its
frame. So it might be worth to fix this.
martin
next prev parent reply other threads:[~2012-12-22 17:42 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-19 8:12 bug#13225: 24.3.50; Non-selected window has not mode-line-inactive face martin rudalics
2012-12-19 16:07 ` Eli Zaretskii
2012-12-19 18:30 ` Stefan Monnier
2012-12-19 19:16 ` Drew Adams
2012-12-19 19:28 ` Drew Adams
2012-12-19 20:07 ` Stefan Monnier
2012-12-19 20:56 ` Drew Adams
2012-12-20 0:52 ` Stefan Monnier
2012-12-19 21:36 ` Eli Zaretskii
2012-12-20 2:08 ` Stefan Monnier
2012-12-20 9:59 ` martin rudalics
2012-12-20 14:03 ` Stefan Monnier
2012-12-20 16:28 ` Eli Zaretskii
2012-12-20 17:24 ` martin rudalics
2012-12-20 17:37 ` Eli Zaretskii
2012-12-21 9:15 ` martin rudalics
2012-12-21 9:35 ` Eli Zaretskii
2012-12-21 14:24 ` martin rudalics
2012-12-21 14:43 ` Eli Zaretskii
2012-12-20 17:25 ` martin rudalics
2012-12-20 18:07 ` Stefan Monnier
2012-12-21 9:16 ` martin rudalics
2012-12-22 15:52 ` Stefan Monnier
2012-12-22 16:05 ` martin rudalics
2012-12-22 16:56 ` Stefan Monnier
2012-12-22 17:42 ` martin rudalics [this message]
2012-12-23 13:41 ` Stefan Monnier
2012-12-23 14:03 ` martin rudalics
2012-12-23 15:40 ` Stefan Monnier
2012-12-20 9:59 ` martin rudalics
2012-12-20 17:09 ` Eli Zaretskii
2012-12-20 17:24 ` martin rudalics
2013-01-04 8:28 ` Glenn Morris
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=50D5F0EC.9060303@gmx.at \
--to=rudalics@gmx.at \
--cc=13225@debbugs.gnu.org \
--cc=monnier@iro.umontreal.ca \
/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).