From: Eli Zaretskii <eliz@gnu.org>
To: martin rudalics <rudalics@gmx.at>
Cc: 12600@debbugs.gnu.org
Subject: bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame
Date: Sat, 13 Oct 2012 20:08:37 +0200 [thread overview]
Message-ID: <83obk65joa.fsf@gnu.org> (raw)
In-Reply-To: <5079A8B0.7050000@gmx.at>
> Date: Sat, 13 Oct 2012 19:45:20 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: monnier@iro.umontreal.ca, 12600@debbugs.gnu.org
>
> >> (1) Change the window's buffer via `set-window-buffer'.
> >
> > This is taken care of by setting windows_or_buffers_changed.
>
> windows_or_buffers_changed is a global flag. How does redisplay find
> out _which_ window got a new buffer? Or does redisplay not care?
It doesn't care, in the sense that it always considers every window.
It _does_ care, in the sense that certain redisplay optimizations are
turned off when windows_or_buffers_changed is non-zero.
E.g., if nothing's changed since the last redisplay, then redisplay
will only enter try_cursor_movement for each window, quickly see that
point didn't move, and exit without doing anything. But if
windows_or_buffers_changed is non-zero, this optimizations is
disabled.
> >> (2) Change the size of the window (including toggling of scrollbars and
> >> fringes).
> >
> > Redisplay figures this out already, I think. Which commands/functions
> > make these changes?
>
> They all end up calling window_resize_apply.
They all also set windows_or_buffers_changed non-zero. So I think
these cases are already covered, as far as redisplay is concerned.
>
> >> (3) Change the buffer's position in the window (usually via scrolling,
> >> `set-window-point' and `set-window-start').
> >
> > These likewise set windows_or_buffers_changed, so they shouldn't be a
> > problem.
>
> But usually they affect only one window. Again, redisplay might not
> care. But I would be surprised that it doesn't handle such a simple
> case of optimization.
It tries. It disables fewer optimizations when last_modified is reset
than when windows_or_buffers_changed is non-zero. But I doubt that
this difference shows in many important situations. At least resizing
a window never affects only one window.
> >> Now in all of these cases, the respective routines in window.c would set
> >> the window's last_modified_flag to t, marking the window as dirty.
> >
> > I don't think this is necessary. Can you try without setting this
> > flag, and see if anything breaks?
>
> I said "would". last_modified_flag doesn't exist.
The same should be tru for the last_modified and last_overlay_modified
fields, which do exist.
> >> So why do we currently reset last_modified and last_overlay_modified in
> >> window.c?
> >
> > See above. Maybe I'm missing something, but
> > windows_or_buffers_changed should take care of all of this.
>
> OK. I'll comment them out after the feature freeze and we'll see ;-)
Thanks.
> Replace the three struct members last_modified, last_overlay_modified
> and window_end_valid by one struct member called last_modified_flag -
> actually calling it window_modified would be better. Set
> window_modified to t wherever we currently reset one of the three
> members. Redisplay, when fully done, would reset window_modified to nil
> for every window it completes instead of setting the other members.
And when a buffer is modified or its overlays are modified, what
should we do to indicate to redisplay that the corresponding windows
might need a more thorough redisplay?
next prev parent reply other threads:[~2012-10-13 18:08 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-07 23:03 bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame Christoph Scholtes
2012-10-08 7:31 ` Eli Zaretskii
2012-10-08 9:17 ` martin rudalics
2012-10-08 13:59 ` Stefan Monnier
2012-10-08 15:48 ` Eli Zaretskii
2012-10-09 9:36 ` martin rudalics
2012-10-09 17:04 ` Eli Zaretskii
2012-10-10 10:22 ` martin rudalics
2012-10-10 15:45 ` Eli Zaretskii
2012-10-11 7:12 ` martin rudalics
2012-10-11 16:56 ` Eli Zaretskii
2012-10-12 7:32 ` martin rudalics
2012-10-12 8:52 ` Eli Zaretskii
2012-10-12 9:35 ` martin rudalics
2012-10-12 13:51 ` Eli Zaretskii
2012-10-12 15:42 ` martin rudalics
2012-10-12 14:55 ` Stefan Monnier
2012-10-12 15:36 ` Eli Zaretskii
2012-10-12 15:43 ` martin rudalics
2012-10-13 8:56 ` Eli Zaretskii
2012-10-13 9:51 ` martin rudalics
2012-10-13 12:45 ` Eli Zaretskii
2012-10-13 17:45 ` martin rudalics
2012-10-13 18:08 ` Eli Zaretskii [this message]
2012-10-14 10:21 ` martin rudalics
2012-10-14 12:06 ` Eli Zaretskii
2012-10-14 18:33 ` martin rudalics
2012-10-14 20:01 ` Eli Zaretskii
2012-10-15 9:41 ` martin rudalics
2012-10-15 19:39 ` Eli Zaretskii
2012-10-16 9:39 ` martin rudalics
2012-10-16 17:35 ` Eli Zaretskii
2012-10-15 9:40 ` martin rudalics
2012-11-09 9:49 ` 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83obk65joa.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=12600@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 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.