From: storm@cua.dk (Kim F. Storm)
Cc: Tak Ota <Takaaki.Ota@am.sony.com>, emacs-devel@gnu.org
Subject: Re: redundant redisplay
Date: 28 Apr 2004 03:37:17 +0200 [thread overview]
Message-ID: <m3y8og288i.fsf@kfs-l.imdomain.dk> (raw)
In-Reply-To: <x5isfl2l9b.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> writes:
> Tak Ota <Takaaki.Ota@am.sony.com> writes:
>
> > Some recent change, which I cannot identify, affects the redisplay
> > mechanism so that set-buffer-modified-p redisplays window contents
> > redundantly. It creates occasional annoying partial screen flashing
> > as well as considerably slows down a buffer process which updates
> > modeline frequently.
>
> >From the Elisp manual:
>
> - Function: set-buffer-modified-p flag
> This function marks the current buffer as modified if FLAG is
> non-`nil', or as unmodified if the flag is `nil'.
>
> Another effect of calling this function is to cause unconditional
> redisplay of the mode line for the current buffer. In fact, the
> function `force-mode-line-update' works by doing this:
>
> (set-buffer-modified-p (buffer-modified-p))
>
> So it _should_ cause a redisplay, but only of the buffer line. Kim,
> are you taking a peek at the line height there, could that be it?
It could be related to my changes of 2004-04-21 (I have a build from
04-18 where it doesn't seem to occur) I just cannot see which change
could cause this.
I can provoke this myself with something like this:
M-x gdb
start another emacs,
C-x 2 (to get two windows)
r -Q
Then move the new emacs frame to overlap the one running gdb.
Now move the cursor (wildly) in the new emacs window and see
the modeline in the old emacs frame flicker.
I tried to trace this a bit, and one thing I saw is that gdb receives
a zillion of frames-invalid messages (here is a dump of the buffer
read from gdb pipe):
\n\032\032frames-invalid\n\n\032\032frames-invalid\n\n\032\032frames-invalid\n\n\032\032frames-invalid\n\n\032\032frames-invalid\n\n\032\032frames-invalid\n\n\032\032frames-invalid\n\n\032\032frames-invalid\n\n\032\032frames-invalid\n\n\032\032frames-invali
Maybe my change did something which causes this to redisplay more
frequently or radically. I'll investigate further tomorrow...
next prev parent reply other threads:[~2004-04-28 1:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-27 17:57 redundant redisplay Tak Ota
2004-04-27 20:56 ` David Kastrup
2004-04-28 1:37 ` Kim F. Storm [this message]
2004-04-27 22:40 ` Miles Bader
2004-04-28 23:06 ` Kim F. Storm
2004-04-28 23:23 ` Miles Bader
2004-04-29 7:35 ` Tak Ota
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3y8og288i.fsf@kfs-l.imdomain.dk \
--to=storm@cua.dk \
--cc=Takaaki.Ota@am.sony.com \
--cc=emacs-devel@gnu.org \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.