bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#42406: Mouse-wheel scrolling can be flickering


From: Stefan Monnier
Subject: bug#42406: Mouse-wheel scrolling can be flickering
Date: Fri, 18 Dec 2020 18:12:45 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: alan@idiocy.org,  konrad.podczeck@univie.ac.at,  42406@debbugs.gnu.org
>> Date: Fri, 18 Dec 2020 11:22:40 -0500
>> 
>> To be clear: I have no intention to push this to `emacs-27`, but
>> I can't see any good reason not to push it to master (after fixing its
>> FIXME, obviously).
>
> I thought I already explained why I'm not interested in such "fixes".

I resent the way you used scare-quotes around this word.
This *is* a fix and it only touches "flags" whose semantics we
understand well.

Any change to the redisplay will risk introducing regressions because of
the previous code's intricate workings so if you reject this simple
change, I can't see why you wouldn't reject similarly any other change
to the redisplay (including your advocated big redesign).

After all, my `redisplay` bits did pretty much exactly what you suggest
we do, except that they did not try to use a finer distinction between
frametitles, headerlines, modelines, ...

I really just don't understand your stance here.

> Oh, and your question about where the change in mode-line dimensions
> is handled? it's here:
>
>       display_mode_lines (w);
>
>       /* If mode line height has changed, arrange for a thorough
>        immediate redisplay using the correct mode line height.  */
>       if (window_wants_mode_line (w)
>         && CURRENT_MODE_LINE_HEIGHT (w) != DESIRED_MODE_LINE_HEIGHT (w))
>       {
>         f->fonts_changed = true;
>         w->mode_line_height = -1;
>         MATRIX_MODE_LINE_ROW (w->current_matrix)->height
>           = DESIRED_MODE_LINE_HEIGHT (w);
>       }
>       [...]
>       if (f->fonts_changed)
>       goto need_larger_matrices;

Ah, right, thanks, that makes sense.  And it shows that the division
between "mode-lines" and "window contents" was a good idea, since in
most cases they can be handled separately and in the few cases where
they can't, we can easily arrange to augment the amount that's actually
redisplayed once we discover that more needs to be done.


        Stefan






reply via email to

[Prev in Thread] Current Thread [Next in Thread]