From: MON KEY <monkey@sandpframing.com>
To: martin rudalics <rudalics@gmx.at>
Cc: emacs-devel@gnu.org
Subject: Re: force-mode-line-update ALL argument
Date: Sun, 23 May 2010 00:29:48 -0400 [thread overview]
Message-ID: <AANLkTikwFRr-hwMDZTLFFvS0kApRQJ-urHjLQ4q4lBYh@mail.gmail.com> (raw)
In-Reply-To: <4BF79AE5.6010007@gmx.at>
On Sat, May 22, 2010 at 4:50 AM, martin rudalics <rudalics@gmx.at> wrote:
> Thank you for your efforts but I don't get it yet :-(
Me either. Who does?
> What makes you conclude that a `set-buffer' on the value returned by
> `other-buffer' causes updating the modeline
I trust (my assummption) that it does.
I have no way to _visually_ confirm this. Its Kantian Emacsology :P
> of a buffer that maybe has neither been changed nor displayed?
The return value of `other-buffer' is not affected by whether it has been
changed but it does affect it.
> What is a non-visible buffer on a frame?
Precisely that.
> When a buffer is visible it is on a frame.
> When a buffer is not visible it is on no frame.
From :FILE src/buffer.c
/* Switch to buffer B temporarily for redisplay purposes.
This avoids certain things that don't need to be done within redisplay. */
/* Move the assoc for buffer BUF to the front of buffer-alist. Since
we do this each time BUF is selected visibly, the more recently
selected buffers are always closer to the front of the list. This
means that other_buffer is more likely to choose a relevant buffer. */
/* Set the current buffer to B.
We previously set windows_or_buffers_changed here to invalidate
global unchanged information in beg_unchanged and end_unchanged.
This is no longer necessary because we now compute unchanged
information on a buffer-basis. Every action affecting other
windows than the selected one requires a select_window at some
time, and that increments windows_or_buffers_changed. */
> This predicate is set by a buffer change and by nothing else.
If you can't see it how can you be so sure? :P
> The only reason of updating a modeline is when the buffer is visible.
Apparently the redisplay backend doesn't share this perspective.
>
> martin, still hoping that someone can shed light on this issue
>
Good luck! :)
/s_P\
next prev parent reply other threads:[~2010-05-23 4:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-22 5:39 force-mode-line-update ALL argument MON KEY
2010-05-22 8:50 ` martin rudalics
2010-05-23 4:29 ` MON KEY [this message]
2010-05-23 12:16 ` martin rudalics
2010-05-23 17:14 ` MON KEY
2010-05-23 19:05 ` martin rudalics
2010-05-25 2:45 ` MON KEY
-- strict thread matches above, loose matches on Subject: below --
2010-05-20 16:53 martin rudalics
2010-05-21 6:42 ` Tassilo Horn
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=AANLkTikwFRr-hwMDZTLFFvS0kApRQJ-urHjLQ4q4lBYh@mail.gmail.com \
--to=monkey@sandpframing.com \
--cc=emacs-devel@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).