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: Sun, 14 Oct 2012 22:01:06 +0200 [thread overview]
Message-ID: <83y5j84yd9.fsf@gnu.org> (raw)
In-Reply-To: <507B0583.50704@gmx.at>
> 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.
next prev parent reply other threads:[~2012-10-14 20:01 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
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 [this message]
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=83y5j84yd9.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.