From: Tassilo Horn <tsdh@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 20285@debbugs.gnu.org
Subject: bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking
Date: Fri, 10 Apr 2015 15:13:49 +0200 [thread overview]
Message-ID: <877ftkm8he.fsf@gnu.org> (raw)
In-Reply-To: <83h9sotasm.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 10 Apr 2015 15:42:01 +0300")
Eli Zaretskii <eliz@gnu.org> writes:
>> I think that it should be generically possible from Lisp to check if
>> a redisplay has been performed within a given time frame. That might
>> be useful for other stuff next to `blink-cursor-mode', too.
>>
>> That could be achieved by `redisplay' increasing some integer
>> redisplay_counter variable whose value can be accessed from Lisp.
>
> But "was redisplay performed?" does not have a simple yes/no answer.
> Depending on the circumstances, the display engine can decide to
> redisplay one or more windows on one or more frames. By contrast, you
> (in this case) are only interested in the selected window on the
> selected frame. So I don't think a simple counter will cut it; you
> might need a counter per window or some such. And other use cases
> might want something even more fine-granular, perhaps.
In the blink-cursor-mode case, only selected window of the selected
frame is of interest because only there the cursor blinks, and I assume
that the selected window is probably preferred by redisplay, no? But
you are right that this might very well depend on the use-case.
>> Then `blink-cursor-timer-function' could check if the invisibility of
>> the cursor has really been manifested (on the glass) and force a
>> redisplay when toggling it visible again.
>>
>> --8<---------------cut here---------------start------------->8---
>> (defvar blink-cursor-redisplay-counter nil)
>>
>> (defun blink-cursor-timer-function ()
>> "Timer function of timer `blink-cursor-timer'."
>> (let ((cursor-shown (internal-show-cursor-p)))
>> (internal-show-cursor nil (not cursor-shown))
>> ;; If the cursor was invisible in the last cycle and a redisplay has been
>> ;; performed there, ensure a redisplay now so that it won't end up
>> ;; invisible for an indefinite amount of time.
>> (unless (or cursor-shown
>> (= blink-cursor-redisplay-counter
>> redisplay-counter))
>> (redisplay 'force))
>> (setq blink-cursor-redisplay-counter redisplay-counter))
>
> What happens if the blink-cursor timer doesn't get run?
Then you are out of luck.
>> The effect would be that if a timer running too long or processing
>> input stops the blinking of the cursor, that would at happen at least
>> in the visible cursor state.
>
> If it started with the cursor visible, yes. But what if the heavy
> processing started with the cursor blinked off, and the timer function
> didn't get to run for a long time?
Again, you are out of luck then.
But I just verified that the timer function runs pretty regularly. It
might not always be exactly 0.5 seconds between the runs but it's never
deferred for a time which would be clearly observable by a user.
In contrast, it's not seldom that redisplay doesn't happen for up to 10
seconds when emacs is idle but doing heavy processing in the background.
I can easily provoke that situation by compiling a large TeX document
with AUCTeX which puts the tex output in a buffer and has a process
filter on it.
Bye,
Tassilo
next prev parent reply other threads:[~2015-04-10 13:13 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-09 14:50 bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking Tassilo Horn
2015-04-09 15:06 ` Eli Zaretskii
2015-04-09 16:07 ` Eli Zaretskii
2015-04-10 7:46 ` Tassilo Horn
2015-04-10 7:58 ` Eli Zaretskii
2015-04-10 9:28 ` Tassilo Horn
2015-04-10 12:42 ` Eli Zaretskii
2015-04-10 13:13 ` Tassilo Horn [this message]
2015-04-10 13:28 ` Eli Zaretskii
2015-04-10 13:32 ` Eli Zaretskii
2015-04-10 14:13 ` Tassilo Horn
2015-04-10 17:32 ` Eli Zaretskii
2015-04-10 20:52 ` Tassilo Horn
2015-04-11 6:25 ` Eli Zaretskii
2015-04-10 18:24 ` Stefan Monnier
2015-04-10 18:42 ` Eli Zaretskii
2015-04-10 20:21 ` Tassilo Horn
2015-04-10 21:50 ` Stefan Monnier
2015-04-11 5:54 ` Tassilo Horn
2015-04-11 7:34 ` Eli Zaretskii
2015-04-11 11:34 ` Eli Zaretskii
2015-04-11 11:49 ` Tassilo Horn
2015-04-11 12:39 ` Tassilo Horn
2015-04-11 14:45 ` Eli Zaretskii
2015-04-11 19:24 ` Tassilo Horn
2015-04-11 19:45 ` Eli Zaretskii
2015-04-11 20:17 ` Tassilo Horn
2015-04-11 14:02 ` Stefan Monnier
2015-04-11 14:30 ` Tassilo Horn
2015-04-11 14:48 ` Eli Zaretskii
2015-04-11 15:14 ` Eli Zaretskii
2015-04-12 4:05 ` Stefan Monnier
2015-04-11 6:30 ` Eli Zaretskii
2022-04-28 10:50 ` Lars Ingebrigtsen
2022-04-28 11:48 ` Tassilo Horn
2022-04-28 11:51 ` Lars Ingebrigtsen
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877ftkm8he.fsf@gnu.org \
--to=tsdh@gnu.org \
--cc=20285@debbugs.gnu.org \
--cc=eliz@gnu.org \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).