[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh wh
From: |
Eli Zaretskii |
Subject: |
bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame |
Date: |
Sun, 14 Oct 2012 22:01:06 +0200 |
> Date: Sun, 14 Oct 2012 20:33:39 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: monnier@iro.umontreal.ca, 12600@debbugs.gnu.org
>
> > How do you know whether the window's buffer was modified, under your
> > suggestion? Won't we need some record of "the last buffer state when
> > this window was displayed"? E.g., how do we know that point moved
> > since last full redisplay of the window?
>
> If we do not know whether point moved in a buffer since its last
> redisplay, we probably can't optimize anything at all.
We do know, but only because we record that (in w->last_point).
> But we already
> got MODIFF, CHARS_MODIFF, and OVERLAY_MODIFF. What are these good for
> if we always have to redisplay a window showing a buffer whose point
> could have moved since the last redisplay?
Those MODIFF features record actual changes, not cursor motion.
> But apparently
> try_cursor_movement handles this if I understand your text below
> correctly. So why are you asking this?
Because I don't understand your plan to redesign these variables and
flags. I don't see the big picture.
> >> (3) Don't redraw the window otherwise. This would cover the case where
> >> `point' was moved in a buffer not shown in this window or another
> >> window was scrolled.
> >>
> >> This would replace checking of windows_or_buffers_changed with a
> >> finer-grained has "this window or its buffer changed". But after a
> >> cursory look at redisplay_window I doubt that such a change would be
> >> feasible. And I have no idea to which extent (3) is already covered by
> >> try_window_id.
> >
> > The normal "do-nothing" route is to call try_cursor_movement,
>
> So try_cursor_movement cares about the no buffer change, no overlay
> change, no window change, no font change, ... only point movement case.
No, it is only _called_ when there are no changes of the kind you
mention above. If any of these changes are detected,
try_cursor_movement is bypassed, since it is known that it will not do
the job. Here:
/* Handle case where text has not changed, only point, and it has
not moved off the frame, and we are not retrying after hscroll.
(current_matrix_up_to_date_p is nonzero when retrying.) */
if (current_matrix_up_to_date_p
&& (rc = try_cursor_movement (window, startp, &temp_scroll_step),
rc != CURSOR_MOVEMENT_CANNOT_BE_USED))
{
switch (rc)
{
case CURSOR_MOVEMENT_SUCCESS:
used_current_matrix_p = 1;
goto done; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
case CURSOR_MOVEMENT_MUST_SCROLL:
goto try_to_scroll;
default:
emacs_abort ();
}
}
The marked line is the "green channel". It is taken only if
try_cursor_movement succeeds.
And current_matrix_up_to_date_p is computed thusly:
current_matrix_up_to_date_p
= (!NILP (w->window_end_valid)
&& !current_buffer->clip_changed
&& !current_buffer->prevent_redisplay_optimizations_p
&& w->last_modified >= MODIFF
&& w->last_overlay_modified >= OVERLAY_MODIFF);
> > then
> > "goto done". try_window_id is called only if there's some change that
> > requires redisplaying some of the text, not just moving the cursor.
>
> That's what I meant earlier where you replied by asking "how do we know
> that point moved". The various MODIFFs should tell me whether the
> buffer changed. Some other settings tell me whether some font or the
> cursor type changed. And window_modified tells me whether something in
> the window changed that requires to execute try_window_id. If none of
> these changed, the window can stay alone. All this would work only if
> point movement has been handled already.
I'm not sure I understand where you are getting, but to facilitate
this discussion, let me describe the logic of redisplay_window. It
goes like this:
. if nothing changed except possibly point, call
try_cursor_movement; if that succeeds, we are done
. otherwise, if the buffer is unchanged, try reusing some of the
current glyph matrix, assuming that just the window-start has
changed -- this is what try_window_reusing_current_matrix does
. if that fails, call try_window_id, which tries reusing of the
current glyph matrix, assuming that only some lines at the
beginning or the end of the window have changed
. if that fails, too, call try_window to redisplay the entire window
using the previous window-start point
. if try_window finds that point ends up outside the window,
"scroll" the window, i.e. find a better window-start point such
that point enters the window -- this is what try_scrolling does
. if that fails as well, compute the new window-start and redisplay
the entire window starting from there
> This would mean that try_cursor_movement had instead of
>
> && !windows_or_buffers_changed
>
> check
>
> && !w->window_modified
>
> and the respective MODIFF conjuncts for w's buffer.
What would we gain by this change?
> BTW, couldn't we instead of
>
> && !(!NILP (Vtransient_mark_mode)
> && !NILP (BVAR (current_buffer, mark_active)))
>
> use the more human
>
> && (NILP (Vtransient_mark_mode)
> || NILP (BVAR (current_buffer, mark_active)))
>
> here?
It depends on how you reason about logic. To me, the condition
!NILP (Vtransient_mark_mode)
&& !NILP (BVAR (current_buffer, mark_active))
is clear, whereas its reverse is less so.
- bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame, (continued)
- bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame, Eli Zaretskii, 2012/10/12
- bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame, martin rudalics, 2012/10/12
- bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame, Eli Zaretskii, 2012/10/13
- bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame, martin rudalics, 2012/10/13
- bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame, Eli Zaretskii, 2012/10/13
- bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame, martin rudalics, 2012/10/13
- bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame, Eli Zaretskii, 2012/10/13
- bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame, martin rudalics, 2012/10/14
- bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame, Eli Zaretskii, 2012/10/14
- bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame, martin rudalics, 2012/10/14
- bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame,
Eli Zaretskii <=
- bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame, martin rudalics, 2012/10/15
- bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame, Eli Zaretskii, 2012/10/15
- bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame, martin rudalics, 2012/10/16
- bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame, Eli Zaretskii, 2012/10/16
bug#12600: 24.2.50; linum-mode: line numbers in fringe do not refresh when resizing frame, martin rudalics, 2012/10/15