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: Thu, 17 Dec 2020 14:45:19 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

> force-mode-line-update should only be needed when changes in the mode
> line are displayed in the middle of running Lisp code.

I think the calls to `force-mode-line-update` in minor mode functions
beg to disagree.  E.g.

    src/emacs -Q --eval '(global-set-key "a" (lambda () (interactive) (setq 
abbrev-mode (not abbrev-mode))))'

you'll notice that hitting `a` doesn't change the mode line to reflect
the change in `abbrev-mode`.

> We should stop lumping heuristics one on top another, and instead
> redesign this from scratch and make sure that every flag we set is
> acted upon as intended, and only in situations we intend them to be
> acted upon.  E.g., we should be able to set f->redisplay to a value
> that means "update only the frame title".

The `redisplay` bit is not supposed to be a heuristic at all.  It just
tried to keep track more precisely of which part of the redisplay may
have changed.  `fset_redisplay` marks the frame to be redisplayed at the
next redisplay, setting `update_mode_lines` to a non-zero value means
that when redisplaying a window we also redisplay its mode line, so
the suggested hunk definitely doesn't rely on any kind of heuristic.

[ Any chance you got confused thinking that my patch intended to
  stop updating the column/line numbers in frame titles?
  It's most definitely not: the "This said" in my message divides two
  different proposed ways to attack the problem.  ]

The main problems I see with my suggested patch are:
- I don't know if it actually fixes the original problem.
- It can cause *more* redisplay work because it will force redisplay of
  all the windows in the current frame (rather than only their mode
  lines).

> I'm not against experimenting with replacing 42 by 32 or by
> REDISPLAY_SOME etc., but I don't think we should install anything
> along these lines, except if we need to fix a clear bug (i.e. a
> redisplay glitch), which this one isn't.

I don't know what you mean by "along these lines".


        Stefan






reply via email to

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