Emacs uses CPU when this mode is enabled

[oscarfv]

First of all: very nice package, thank you!

I noticed that with this mode active Emacs uses ~1-2% of one CPU core when sitting idle. I tried setting mini-modeline-update-interval to a larger value (0.3), but that had no effect.

[oscarfv]

The problem comes from the timer. Currently I'm experimenting with an idle timer instead.

By the way, this code:

(when (timerp (cancel-timer mini-modeline--timer)))

probably should be:

(when (timerp mini-modeline--timer) (cancel-timer mini-modeline--timer))

[kiennq]

Nice. PR is welcome :D

[slotThe]

This is perhaps tangentially related, but I wonder why in mini-modeline--timer, the run-with-timer function is always called with a repeat of 0.1

(setq mini-modeline--timer (run-with-timer 0 0.1 #'mini-modeline-display))

and then we are checking if we actually have the right update interval in mini-modeline-display

when (or (memq arg '(force clear))
                          (mini-modeline--overduep mini-modeline--last-update
                                                   mini-modeline-update-interval))              

Wouldn't it make more sense to call

(setq mini-modeline--timer (run-with-timer 0 mini-modeline-update-interval #'mini-modeline-display))

directly and get rid of the mini-modeline--last-update variable entirely (which, as far as I can tell, is not used anywhere else)?

[andersjohansson]

This is perhaps tangentially related, but I wonder why in mini-modeline--timer, the run-with-timer function is always called with a repeat of 0.1

(setq mini-modeline--timer (run-with-timer 0 0.1 #'mini-modeline-display))

and then we are checking if we actually have the right update interval in mini-modeline-display

when (or (memq arg '(force clear))
                          (mini-modeline--overduep mini-modeline--last-update
                                                   mini-modeline-update-interval))              

Wouldn't it make more sense to call

(setq mini-modeline--timer (run-with-timer 0 mini-modeline-update-interval #'mini-modeline-display))

directly and get rid of the mini-modeline--last-update variable entirely (which, as far as I can tell, is not used anywhere else)?

@slotThe, when using an idle-timer, as in #57, I believe it makes more sense to do this kind of check, since the idle timer can fire kind of whenever. But then again, if mini-modeline-update-interval <= the timer interval, (both are 0.1 in by default in #57 it would probably mean that it should always update when it is called (through the timer).

[slotThe]

@slotThe, when using an idle-timer, as in #57, I believe it makes more sense to do this kind of check, since the idle timer can fire kind of whenever. But then again, if mini-modeline-update-interval <= the timer interval, (both are 0.1 in by default in #57 it would probably mean that it should always update when it is called (through the timer).

Indeed, I think with an idle timer—which seems like the best solution anyways—it would make sense again

[10ne1]

FWIW I use this modification along with the following config and mini-modeline works quite smooth on my machines, without any flickering (that's why I suppress some mostly useless error signals) or noticeable UI slowdowns (the don't pause redisplay). I am not sure about CPU usage because I tend to run lots of stuff in emacs/EXWM so some cpu usage is expected. Haven't yet investigated if / how it can be reduced.

(setq redisplay-dont-pause nil)

(defun my-command-error-function (data context caller)
  "Ignore the buffer-read-only, beginning-of-buffer,
end-of-buffer signals; pass the rest to the default handler."
  (when (not (memq (car data) '(buffer-read-only
                                beginning-of-buffer
                                end-of-buffer
				quit)))
    (command-error-default-function data context caller)))

(setq command-error-function #'my-command-error-function)

(add-hook 'before-make-frame-hook 'mini-modeline-mode)