bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking

bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking

[Tassilo Horn]

Sometimes it occurs to me that `blink-cursor-mode' stops blinking the
cursor for some time.  That temporary stop might also occur in the
off-phase so that there's no visible cursor anymore.  As soon as I press
some key, the blinking starts again.  But just now in some specific
buffer, it'll blink twice and then disappear until I press a key again.

I've set `blink-cursor-blinks' to 0 so that blinking should not stop
after a given number of blinks.

I've added some messages to `blink-cursor-start', `blink-cursor-stop'.
It looks like whenever I switch windows, first the timer is stopped and
then started again.  I did that because C-h v blink-cursor-timer always
said it was nil.  The same happened when trying to get it using

  (with-current-buffer "some-buffer" blink-cursor-timer)

or

  (progn (switch-to-buffer "some-buffer") blink-cursor-timer)

Anyway, the timer seems to be there.

Then I added a (message "BLINK") as the first form in
`blink-cursor-timer-function'.  And strangely, when the blinking stops
for whatever reason, I can still see BLINK [53 times] with increasing
repetition count in *Messages*.  So the problem seems to be that

  (internal-show-cursor nil (not (internal-show-cursor-p)))

stops working for some unknown reason.  Then I changed my message to

  (message "BLINK: %s" (internal-show-cursor-p))

and now I get alternating

  BLINK: nil
  BLINK: t

sequences even though the cursor has stopped blinking already.  So I
guess the problem is that no redisplay is performed which would make the
visibility toggle of the cursor effective, and thus don't notice that
the cursor should have been visible/invisible for the last half of a
second.

Of course, that doesn't happen always and I've not been able reproduce
it using emacs -Q.  I think I get this problem most frequently when
editing large LaTeX files with AUCTeX but I think I got it also in some
other buffers already, so this observation might only show that I'm
writing LaTeX documents a good bit of my time.




In GNU Emacs 25.0.50.10 (x86_64-unknown-linux-gnu, GTK+ Version 3.14.9)
 of 2015-04-09 on thinkpad-t440p
Repository revision: c9415ccbf84fce152e0f4b98ac2ed60680272a47
Windowing system distributor `The X.Org Foundation', version 11.0.11701000
System Description:	Arch Linux

Configured using:
 `configure CFLAGS=-DTRACE_SELECTION'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB

Important settings:
  value of $LC_MONETARY: de_DE.utf8
  value of $LC_NUMERIC: de_DE.utf8
  value of $LC_TIME: de_DE.utf8
  value of $LANG: en_US.utf8
  locale-coding-system: utf-8-unix

Major mode: LaTeX/PS

Minor modes in effect:
  diff-auto-refine-mode: t
  auto-dictionary-mode: t
  flyspell-mode: t
  reftex-mode: t
  th/LaTeX-command-section-mode: t
  TeX-PDF-mode: t
  TeX-source-correlate-mode: t
  global-company-mode: t
  global-aggressive-indent-mode: t
  global-edit-server-edit-mode: t
  pdf-occur-global-minor-mode: t
  recentf-mode: t
  shell-dirtrack-mode: t
  outline-minor-mode: t
  helm-autoresize-mode: t
  th/sentence-hl-mode: t
  global-subword-mode: t
  subword-mode: t
  savehist-mode: t
  show-paren-mode: t
  icomplete-mode: t
  minibuffer-depth-indicate-mode: t
  electric-pair-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t

Recent messages:
user-error: Minibuffer is inactive [2 times]
Mark set
Auto-saving...done
Saving file /home/horn/Repos/uni/diss/diss.tex...
Wrote /home/horn/Repos/uni/diss/diss.tex
Mark set
Saving file /home/horn/Repos/uni/diss/_region_.tex...
Wrote /home/horn/Repos/uni/diss/_region_.tex
Type `C-c C-l' to display results of compilation.
LaTeX: there were unresolved references, {23} pages
Quit

Load-path shadows:
~/Repos/el/auctex/lpath hides ~/Repos/el/gnus/lisp/lpath
~/Repos/el/gnus/lisp/md4 hides /home/horn/Repos/el/emacs/lisp/md4
~/Repos/el/gnus/lisp/color hides /home/horn/Repos/el/emacs/lisp/color
~/Repos/el/gnus/lisp/format-spec hides /home/horn/Repos/el/emacs/lisp/format-spec
~/Repos/el/gnus/lisp/password-cache hides /home/horn/Repos/el/emacs/lisp/password-cache
~/Repos/el/gnus/lisp/hex-util hides /home/horn/Repos/el/emacs/lisp/hex-util
~/Repos/el/gnus/lisp/dns-mode hides /home/horn/Repos/el/emacs/lisp/textmodes/dns-mode
~/Repos/el/gnus/lisp/dig hides /home/horn/Repos/el/emacs/lisp/net/dig
~/Repos/el/gnus/lisp/hmac-md5 hides /home/horn/Repos/el/emacs/lisp/net/hmac-md5
~/Repos/el/gnus/lisp/ntlm hides /home/horn/Repos/el/emacs/lisp/net/ntlm
~/Repos/el/gnus/lisp/hmac-def hides /home/horn/Repos/el/emacs/lisp/net/hmac-def
~/Repos/el/gnus/lisp/rfc2104 hides /home/horn/Repos/el/emacs/lisp/net/rfc2104
~/Repos/el/gnus/lisp/sasl-ntlm hides /home/horn/Repos/el/emacs/lisp/net/sasl-ntlm
~/Repos/el/gnus/lisp/sasl-cram hides /home/horn/Repos/el/emacs/lisp/net/sasl-cram
~/Repos/el/gnus/lisp/dns hides /home/horn/Repos/el/emacs/lisp/net/dns
~/Repos/el/gnus/lisp/sasl hides /home/horn/Repos/el/emacs/lisp/net/sasl
~/Repos/el/gnus/lisp/tls hides /home/horn/Repos/el/emacs/lisp/net/tls
~/Repos/el/gnus/lisp/sasl-scram-rfc hides /home/horn/Repos/el/emacs/lisp/net/sasl-scram-rfc
~/Repos/el/gnus/lisp/netrc hides /home/horn/Repos/el/emacs/lisp/net/netrc
~/Repos/el/gnus/lisp/sasl-digest hides /home/horn/Repos/el/emacs/lisp/net/sasl-digest
~/Repos/el/gnus/lisp/uudecode hides /home/horn/Repos/el/emacs/lisp/mail/uudecode
~/Repos/el/gnus/lisp/binhex hides /home/horn/Repos/el/emacs/lisp/mail/binhex
~/Repos/el/gnus/lisp/hashcash hides /home/horn/Repos/el/emacs/lisp/mail/hashcash
~/Repos/el/gnus/lisp/canlock hides /home/horn/Repos/el/emacs/lisp/gnus/canlock
~/Repos/el/gnus/lisp/nneething hides /home/horn/Repos/el/emacs/lisp/gnus/nneething
~/Repos/el/gnus/lisp/mm-encode hides /home/horn/Repos/el/emacs/lisp/gnus/mm-encode
~/Repos/el/gnus/lisp/mm-util hides /home/horn/Repos/el/emacs/lisp/gnus/mm-util
~/Repos/el/gnus/lisp/rfc2047 hides /home/horn/Repos/el/emacs/lisp/gnus/rfc2047
~/Repos/el/gnus/lisp/nnml hides /home/horn/Repos/el/emacs/lisp/gnus/nnml
~/Repos/el/gnus/lisp/gnus-cus hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-cus
~/Repos/el/gnus/lisp/gnus-range hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-range
~/Repos/el/gnus/lisp/gnus-int hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-int
~/Repos/el/gnus/lisp/gnus-cloud hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-cloud
~/Repos/el/gnus/lisp/spam-stat hides /home/horn/Repos/el/emacs/lisp/gnus/spam-stat
~/Repos/el/gnus/lisp/nnmh hides /home/horn/Repos/el/emacs/lisp/gnus/nnmh
~/Repos/el/gnus/lisp/gnus-mlspl hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-mlspl
~/Repos/el/gnus/lisp/deuglify hides /home/horn/Repos/el/emacs/lisp/gnus/deuglify
~/Repos/el/gnus/lisp/gnus-gravatar hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-gravatar
~/Repos/el/gnus/lisp/nngateway hides /home/horn/Repos/el/emacs/lisp/gnus/nngateway
~/Repos/el/gnus/lisp/ietf-drums hides /home/horn/Repos/el/emacs/lisp/gnus/ietf-drums
~/Repos/el/gnus/lisp/mail-parse hides /home/horn/Repos/el/emacs/lisp/gnus/mail-parse
~/Repos/el/gnus/lisp/gnus-salt hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-salt
~/Repos/el/gnus/lisp/nnimap hides /home/horn/Repos/el/emacs/lisp/gnus/nnimap
~/Repos/el/gnus/lisp/gnus-draft hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-draft
~/Repos/el/gnus/lisp/mail-source hides /home/horn/Repos/el/emacs/lisp/gnus/mail-source
~/Repos/el/gnus/lisp/messcompat hides /home/horn/Repos/el/emacs/lisp/gnus/messcompat
~/Repos/el/gnus/lisp/pop3 hides /home/horn/Repos/el/emacs/lisp/gnus/pop3
~/Repos/el/gnus/lisp/nnmaildir hides /home/horn/Repos/el/emacs/lisp/gnus/nnmaildir
~/Repos/el/gnus/lisp/nnheader hides /home/horn/Repos/el/emacs/lisp/gnus/nnheader
~/Repos/el/gnus/lisp/gnus-cite hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-cite
~/Repos/el/gnus/lisp/nndiary hides /home/horn/Repos/el/emacs/lisp/gnus/nndiary
~/Repos/el/gnus/lisp/gnus-diary hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-diary
~/Repos/el/gnus/lisp/nnfolder hides /home/horn/Repos/el/emacs/lisp/gnus/nnfolder
~/Repos/el/gnus/lisp/gnus-art hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-art
~/Repos/el/gnus/lisp/gnus-demon hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-demon
~/Repos/el/gnus/lisp/mml-sec hides /home/horn/Repos/el/emacs/lisp/gnus/mml-sec
~/Repos/el/gnus/lisp/nnir hides /home/horn/Repos/el/emacs/lisp/gnus/nnir
~/Repos/el/gnus/lisp/mm-partial hides /home/horn/Repos/el/emacs/lisp/gnus/mm-partial
~/Repos/el/gnus/lisp/gnus-registry hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-registry
~/Repos/el/gnus/lisp/gnus-icalendar hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-icalendar
~/Repos/el/gnus/lisp/compface hides /home/horn/Repos/el/emacs/lisp/gnus/compface
~/Repos/el/gnus/lisp/gnus-fun hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-fun
~/Repos/el/gnus/lisp/gnus-start hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-start
~/Repos/el/gnus/lisp/smiley hides /home/horn/Repos/el/emacs/lisp/gnus/smiley
~/Repos/el/gnus/lisp/gnus-picon hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-picon
~/Repos/el/gnus/lisp/spam-report hides /home/horn/Repos/el/emacs/lisp/gnus/spam-report
~/Repos/el/gnus/lisp/nntp hides /home/horn/Repos/el/emacs/lisp/gnus/nntp
~/Repos/el/gnus/lisp/nnnil hides /home/horn/Repos/el/emacs/lisp/gnus/nnnil
~/Repos/el/gnus/lisp/nndir hides /home/horn/Repos/el/emacs/lisp/gnus/nndir
~/Repos/el/gnus/lisp/gnus-srvr hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-srvr
~/Repos/el/gnus/lisp/smime hides /home/horn/Repos/el/emacs/lisp/gnus/smime
~/Repos/el/gnus/lisp/nnvirtual hides /home/horn/Repos/el/emacs/lisp/gnus/nnvirtual
~/Repos/el/gnus/lisp/gnus-notifications hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-notifications
~/Repos/el/gnus/lisp/nnspool hides /home/horn/Repos/el/emacs/lisp/gnus/nnspool
~/Repos/el/gnus/lisp/gnus-group hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-group
~/Repos/el/gnus/lisp/gnus-bcklg hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-bcklg
~/Repos/el/gnus/lisp/gnus-util hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-util
~/Repos/el/gnus/lisp/gnus-sieve hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-sieve
~/Repos/el/gnus/lisp/nndraft hides /home/horn/Repos/el/emacs/lisp/gnus/nndraft
~/Repos/el/gnus/lisp/nnagent hides /home/horn/Repos/el/emacs/lisp/gnus/nnagent
~/Repos/el/gnus/lisp/gnus-spec hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-spec
~/Repos/el/gnus/lisp/gnus-bookmark hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-bookmark
~/Repos/el/gnus/lisp/mml1991 hides /home/horn/Repos/el/emacs/lisp/gnus/mml1991
~/Repos/el/gnus/lisp/rfc2231 hides /home/horn/Repos/el/emacs/lisp/gnus/rfc2231
~/Repos/el/gnus/lisp/yenc hides /home/horn/Repos/el/emacs/lisp/gnus/yenc
~/Repos/el/gnus/lisp/gnus-undo hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-undo
~/Repos/el/gnus/lisp/ecomplete hides /home/horn/Repos/el/emacs/lisp/gnus/ecomplete
~/Repos/el/gnus/lisp/legacy-gnus-agent hides /home/horn/Repos/el/emacs/lisp/gnus/legacy-gnus-agent
~/Repos/el/gnus/lisp/utf7 hides /home/horn/Repos/el/emacs/lisp/gnus/utf7
~/Repos/el/gnus/lisp/rtree hides /home/horn/Repos/el/emacs/lisp/gnus/rtree
~/Repos/el/gnus/lisp/gnus-uu hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-uu
~/Repos/el/gnus/lisp/gnus-ml hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-ml
~/Repos/el/gnus/lisp/sieve hides /home/horn/Repos/el/emacs/lisp/gnus/sieve
~/Repos/el/gnus/lisp/gnus hides /home/horn/Repos/el/emacs/lisp/gnus/gnus
~/Repos/el/gnus/lisp/mml hides /home/horn/Repos/el/emacs/lisp/gnus/mml
~/Repos/el/gnus/lisp/message hides /home/horn/Repos/el/emacs/lisp/gnus/message
~/Repos/el/gnus/lisp/mml-smime hides /home/horn/Repos/el/emacs/lisp/gnus/mml-smime
~/Repos/el/gnus/lisp/gnus-eform hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-eform
~/Repos/el/gnus/lisp/gnus-agent hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-agent
~/Repos/el/gnus/lisp/gnus-logic hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-logic
~/Repos/el/gnus/lisp/mm-extern hides /home/horn/Repos/el/emacs/lisp/gnus/mm-extern
~/Repos/el/gnus/lisp/nndoc hides /home/horn/Repos/el/emacs/lisp/gnus/nndoc
~/Repos/el/gnus/lisp/sieve-manage hides /home/horn/Repos/el/emacs/lisp/gnus/sieve-manage
~/Repos/el/gnus/lisp/mm-decode hides /home/horn/Repos/el/emacs/lisp/gnus/mm-decode
~/Repos/el/gnus/lisp/starttls hides /home/horn/Repos/el/emacs/lisp/gnus/starttls
~/Repos/el/gnus/lisp/gnus-dired hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-dired
~/Repos/el/gnus/lisp/nnbabyl hides /home/horn/Repos/el/emacs/lisp/gnus/nnbabyl
~/Repos/el/gnus/lisp/nnmbox hides /home/horn/Repos/el/emacs/lisp/gnus/nnmbox
~/Repos/el/gnus/lisp/gnus-win hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-win
~/Repos/el/gnus/lisp/gnus-async hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-async
~/Repos/el/gnus/lisp/mm-url hides /home/horn/Repos/el/emacs/lisp/gnus/mm-url
~/Repos/el/gnus/lisp/gnus-html hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-html
~/Repos/el/gnus/lisp/gssapi hides /home/horn/Repos/el/emacs/lisp/gnus/gssapi
~/Repos/el/gnus/lisp/mml2015 hides /home/horn/Repos/el/emacs/lisp/gnus/mml2015
~/Repos/el/gnus/lisp/nnrss hides /home/horn/Repos/el/emacs/lisp/gnus/nnrss
~/Repos/el/gnus/lisp/gnus-mh hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-mh
~/Repos/el/gnus/lisp/gnus-sum hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-sum
~/Repos/el/gnus/lisp/nnweb hides /home/horn/Repos/el/emacs/lisp/gnus/nnweb
~/Repos/el/gnus/lisp/mail-prsvr hides /home/horn/Repos/el/emacs/lisp/gnus/mail-prsvr
~/Repos/el/gnus/lisp/nnmairix hides /home/horn/Repos/el/emacs/lisp/gnus/nnmairix
~/Repos/el/gnus/lisp/plstore hides /home/horn/Repos/el/emacs/lisp/gnus/plstore
~/Repos/el/gnus/lisp/rfc2045 hides /home/horn/Repos/el/emacs/lisp/gnus/rfc2045
~/Repos/el/gnus/lisp/gnus-msg hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-msg
~/Repos/el/gnus/lisp/spam-wash hides /home/horn/Repos/el/emacs/lisp/gnus/spam-wash
~/Repos/el/gnus/lisp/gnus-score hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-score
~/Repos/el/gnus/lisp/mm-uu hides /home/horn/Repos/el/emacs/lisp/gnus/mm-uu
~/Repos/el/gnus/lisp/spam hides /home/horn/Repos/el/emacs/lisp/gnus/spam
~/Repos/el/gnus/lisp/mm-view hides /home/horn/Repos/el/emacs/lisp/gnus/mm-view
~/Repos/el/gnus/lisp/sieve-mode hides /home/horn/Repos/el/emacs/lisp/gnus/sieve-mode
~/Repos/el/gnus/lisp/html2text hides /home/horn/Repos/el/emacs/lisp/gnus/html2text
~/Repos/el/gnus/lisp/gnus-ems hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-ems
~/Repos/el/gnus/lisp/registry hides /home/horn/Repos/el/emacs/lisp/gnus/registry
~/Repos/el/gnus/lisp/auth-source hides /home/horn/Repos/el/emacs/lisp/gnus/auth-source
~/Repos/el/gnus/lisp/gravatar hides /home/horn/Repos/el/emacs/lisp/gnus/gravatar
~/Repos/el/gnus/lisp/flow-fill hides /home/horn/Repos/el/emacs/lisp/gnus/flow-fill
~/Repos/el/gnus/lisp/gmm-utils hides /home/horn/Repos/el/emacs/lisp/gnus/gmm-utils
~/Repos/el/gnus/lisp/mailcap hides /home/horn/Repos/el/emacs/lisp/gnus/mailcap
~/Repos/el/gnus/lisp/gnus-delay hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-delay
~/Repos/el/gnus/lisp/mm-bodies hides /home/horn/Repos/el/emacs/lisp/gnus/mm-bodies
~/Repos/el/gnus/lisp/mm-archive hides /home/horn/Repos/el/emacs/lisp/gnus/mm-archive
~/Repos/el/gnus/lisp/rfc1843 hides /home/horn/Repos/el/emacs/lisp/gnus/rfc1843
~/Repos/el/gnus/lisp/gnus-kill hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-kill
~/Repos/el/gnus/lisp/qp hides /home/horn/Repos/el/emacs/lisp/gnus/qp
~/Repos/el/gnus/lisp/score-mode hides /home/horn/Repos/el/emacs/lisp/gnus/score-mode
~/Repos/el/gnus/lisp/gnus-topic hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-topic
~/Repos/el/gnus/lisp/gnus-cache hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-cache
~/Repos/el/gnus/lisp/nnmail hides /home/horn/Repos/el/emacs/lisp/gnus/nnmail
~/Repos/el/gnus/lisp/gnus-vm hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-vm
~/Repos/el/gnus/lisp/gnus-sync hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-sync
~/Repos/el/gnus/lisp/nnoo hides /home/horn/Repos/el/emacs/lisp/gnus/nnoo
~/Repos/el/gnus/lisp/nnregistry hides /home/horn/Repos/el/emacs/lisp/gnus/nnregistry
~/Repos/el/gnus/lisp/gnus-dup hides /home/horn/Repos/el/emacs/lisp/gnus/gnus-dup
~/Repos/el/gnus/lisp/parse-time hides /home/horn/Repos/el/emacs/lisp/calendar/parse-time
~/Repos/el/gnus/lisp/time-date hides /home/horn/Repos/el/emacs/lisp/calendar/time-date

Features:
(shadow emacsbug sendmail hippie-exp em-unix em-script em-prompt em-ls
em-hist em-pred em-glob em-dirs em-cmpl em-basic em-banner em-alias
esh-var esh-io esh-cmd esh-proc esh-arg esh-groups eshell esh-module
esh-mode misearch multi-isearch pdf-sync pdf-annot pdf-outline pdf-links
pdf-history shr-color color flow-fill reftex-sel reftex-ref reftex-parse
reftex-toc texmathp vc vc-dispatcher vc-git diff-mode preview prv-emacs
auto-dictionary flyspell ispell tex-buf reftex-dcr reftex-auc reftex
reftex-vars font-latex latex tex-style tex dbus crm tex-mode latexenc
winner filecache url-http url-gw url-auth sort gnus-cite smiley shr dom
mm-archive gnus-bcklg qp gnus-async gnus-ml hl-line nndraft nnmh rot13
utf-7 gnutls network-stream nsm starttls nnml nnnil gnus-agent gnus-srvr
gnus-score score-mode nnvirtual gnus-cache gnus-demon nntp spam
spam-stat gnus-uu yenc gnus-msg gnus-gravatar mail-extr gravatar
gnus-topic nnir gnus-registry registry eieio-base th-private
company-files company-oddmuse company-keywords company-etags
company-gtags company-dabbrev-code company-dabbrev company-capf
company-cmake company-xcode company-clang company-semantic company-eclim
company-template company-css company-nxml company-bbdb
highlight-parentheses company finder-inf stratego-mode greql-mode
tg-mode generic preview-latex tex-site auto-loads cider tramp-sh
cider-debug cider-mode cider-repl cider-eldoc cider-interaction arc-mode
archive-mode cider-doc org-table cider-test cider-stacktrace
cider-client nrepl-client queue cider-util ewoc etags xref clojure-mode
paredit aggressive-indent epa-file epa epg rdictcc
google-contacts-message google-contacts derived url-cache google-oauth
google-contacts-gnus gnus-art mm-uu mml2015 mm-view mml-smime smime dig
gnus-sum gnus-group gnus-undo gnus-start gnus-cloud nnimap nnmail
mail-source tls utf7 netrc nnoo parse-time gnus-spec gnus-int gnus-range
gnus-win gnus gnus-ems gnus-compat nnheader em-term term ehelp esh-opt
esh-ext esh-util highlight-symbol boxquote rect ecomplete message rfc822
mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047
rfc2045 ietf-drums mailabbrev mail-utils gmm-utils mailheader
edit-server server haskell-yas yasnippet help-mode cl disp-table
pdf-occur tablist tablist-filter semantic/wisent/comp semantic/wisent
semantic/wisent/wisent semantic/util-modes semantic/util semantic
semantic/tag semantic/lex semantic/fw mode-local cedet pdf-isearch
pdf-misc imenu pdf-tools cus-edit cus-start cus-load pdf-view jka-compr
pdf-cache pdf-info tq pdf-util image-mode browse-kill-ring recentf
tree-widget wid-edit helm-projectile helm-files image-dired tramp
tramp-compat tramp-loaddefs trampver shell dired-x dired-aux ffap
helm-tags helm-bookmark helm-adaptive helm-info bookmark pp
helm-external helm-net browse-url xml url url-proxy url-privacy
url-expand url-methods url-history url-cookie url-domsuf url-util
url-parse auth-source gnus-util mm-util mail-prsvr password-cache
url-vars mailcap helm-buffers helm-match-plugin helm-help helm-org org
org-macro org-footnote org-pcomplete pcomplete org-list org-faces
org-entities noutline outline org-version ob-emacs-lisp ob ob-tangle
ob-ref ob-lob ob-table ob-exp org-src ob-keys ob-comint ob-core ob-eval
org-compat org-macs org-loaddefs format-spec find-func cal-menu calendar
cal-loaddefs helm-grep helm-regexp helm-plugin grep helm-elscreen
helm-utils dired compile comint ansi-color ring helm-locate helm cl-macs
helm-source eieio-compat eieio eieio-core cl-generic byte-opt gv
bytecomp byte-compile cl-extra seq cconv projectile ibuf-ext ibuffer
dash thingatpt helm-config async-bytecomp async helm-aliases easy-mmode
iedit iedit-lib cap-words superword subword saveplace savehist paren
icomplete mb-depth smart-mode-line-respectful-theme
smart-mode-line-light-theme smart-mode-line mule-util rich-minority rx
bs windmove elec-pair edmacro kmacro cl-loaddefs cl-lib gnus-load subr-x
pcase tsdh-light-theme info easymenu memory-usage-autoloads advice
help-fns package epg-config time-date tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd
fontset image regexp-opt fringe tabulated-list newcomment elisp-mode
lisp-mode prog-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer cl-preloaded nadvice loaddefs button faces cus-face
macroexp files text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget hashtable-print-readable backquote
make-network-process dbusbind gfilenotify dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty emacs)

Memory information:
((conses 16 833408 73530)
 (symbols 48 64570 16)
 (miscs 40 11006 14124)
 (strings 32 208060 35941)
 (string-bytes 1 7536199)
 (vectors 16 69824)
 (vector-slots 8 1893933 200157)
 (floats 8 1588 1077)
 (intervals 56 16870 2880)
 (buffers 976 58)
 (heap 1024 126446 102403))

bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Date: Thu, 09 Apr 2015 16:50:56 +0200
> 
> Sometimes it occurs to me that `blink-cursor-mode' stops blinking the
> cursor for some time.  That temporary stop might also occur in the
> off-phase so that there's no visible cursor anymore.  As soon as I press
> some key, the blinking starts again.  But just now in some specific
> buffer, it'll blink twice and then disappear until I press a key again.

It generally means that some other time, probably an idle time, takes
more than 0.5 sec to do its job.

> Then I added a (message "BLINK") as the first form in
> `blink-cursor-timer-function'.  And strangely, when the blinking stops
> for whatever reason, I can still see BLINK [53 times] with increasing
> repetition count in *Messages*.

The contents of "*Messages*" is modified by Lisp code, while to see
the cursor blinking you need to have a redisplay cycle.  Emacs will
not enter redisplay if it has something else to do, like some timer
that is ripe and needs to be run.

> So the problem seems to be that
> 
>   (internal-show-cursor nil (not (internal-show-cursor-p)))
> 
> stops working for some unknown reason.

No, I don't think this conclusion is correct, see above.

> Then I changed my message to
> 
>   (message "BLINK: %s" (internal-show-cursor-p))
> 
> and now I get alternating
> 
>   BLINK: nil
>   BLINK: t
> 
> sequences even though the cursor has stopped blinking already.  So I
> guess the problem is that no redisplay is performed which would make the
> visibility toggle of the cursor effective, and thus don't notice that
> the cursor should have been visible/invisible for the last half of a
> second.

Exactly.

> Of course, that doesn't happen always and I've not been able reproduce
> it using emacs -Q.  I think I get this problem most frequently when
> editing large LaTeX files with AUCTeX but I think I got it also in some
> other buffers already, so this observation might only show that I'm
> writing LaTeX documents a good bit of my time.

Look at your other times, and find the one which takes too much time
for doing its job.

bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking

[Eli Zaretskii]

> Date: Thu, 09 Apr 2015 18:06:01 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 20285@debbugs.gnu.org
> 
> > From: Tassilo Horn <tsdh@gnu.org>
> > Date: Thu, 09 Apr 2015 16:50:56 +0200
> > 
> > Sometimes it occurs to me that `blink-cursor-mode' stops blinking the
> > cursor for some time.  That temporary stop might also occur in the
> > off-phase so that there's no visible cursor anymore.  As soon as I press
> > some key, the blinking starts again.  But just now in some specific
> > buffer, it'll blink twice and then disappear until I press a key again.
> 
> It generally means that some other time, probably an idle time, takes
> more than 0.5 sec to do its job.   ^^^^                   ^^^^

Sorry, "timer".

> Look at your other times, and find the one which takes too much time
> for doing its job. ^^^^^

"timers"

bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> > Sometimes it occurs to me that `blink-cursor-mode' stops blinking the
>> > cursor for some time.  That temporary stop might also occur in the
>> > off-phase so that there's no visible cursor anymore.  As soon as I press
>> > some key, the blinking starts again.  But just now in some specific
>> > buffer, it'll blink twice and then disappear until I press a key again.
>> 
>> It generally means that some other time, probably an idle time, takes
>> more than 0.5 sec to do its job.   ^^^^                   ^^^^
>
> Sorry, "timer".
>
>> Look at your other times, and find the one which takes too much time
>> for doing its job. ^^^^^
>
> "timers"

Yes, got that.  There are quite a few timers in `timer-list' and
`timer-idle-list'.

,----[ C-h v timer-idle-list RET ]
| timer-idle-list is a variable defined in `C source code'.
| Its value is shown below.
| 
| Documentation:
| List of active idle-time timers in order of increasing time.
| 
| Value: ([t 0 0 125000 t show-paren-function nil idle 0]
|  [t 0 0 500000 t jit-lock-context-fontify nil idle 0]
|  [t 0 0 500000 t
|     #[0 "\b\204	\205\n\303>?\205\304 \207"
| 	[eldoc-mode global-eldoc-mode eldoc-documentation-function
| 		    (nil ignore)
| 		    eldoc-print-current-symbol-info]
| 	2]
|     nil idle 0]
|  [t 0 0 500000 t highlight-symbol-temp-highlight nil idle 0]
|  [t 0 0 500000 0.5 blink-cursor-start nil idle 0]
|  [nil 0 1 199999 t reftex-view-crossref-when-idle nil idle 999999]
|  [nil 0 2 0 t adict-guess-dictionary-maybe
|       (#<buffer diss.tex>)
|       idle 0])
`----

Is it documented somewhere what the individual entries of these vectors
mean?  The fifth entry seems to be the SECS or REPEAT argument given to
`run-with-{,idle-}timer', the sixth entry is the function to run, and
the seventh is the function's args, but what are the other entries?

But anyway, I think even when there's some timer that takes too long,
the cursor should never disappear completely.  So maybe a redisplay
should be forced whenever the cursor is set to visible again and there
has been a redisplay when the cursor has been invisible.  That would
ensure that if blinking stops due to a timer or processing of input, at
least it stops in the visible state at the cost of at most one redisplay
which hadn't happened otherwise.

Bye,
Tassilo

bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: 20285@debbugs.gnu.org
> Date: Fri, 10 Apr 2015 09:46:46 +0200
> 
> ,----[ C-h v timer-idle-list RET ]
> | timer-idle-list is a variable defined in `C source code'.
> | Its value is shown below.
> | 
> | Documentation:
> | List of active idle-time timers in order of increasing time.
> | 
> | Value: ([t 0 0 125000 t show-paren-function nil idle 0]
> |  [t 0 0 500000 t jit-lock-context-fontify nil idle 0]
> |  [t 0 0 500000 t
> |     #[0 "\b\204	\205\n\303>?\205\304 \207"
> | 	[eldoc-mode global-eldoc-mode eldoc-documentation-function
> | 		    (nil ignore)
> | 		    eldoc-print-current-symbol-info]
> | 	2]
> |     nil idle 0]
> |  [t 0 0 500000 t highlight-symbol-temp-highlight nil idle 0]
> |  [t 0 0 500000 0.5 blink-cursor-start nil idle 0]
> |  [nil 0 1 199999 t reftex-view-crossref-when-idle nil idle 999999]
> |  [nil 0 2 0 t adict-guess-dictionary-maybe
> |       (#<buffer diss.tex>)
> |       idle 0])
> `----
> 
> Is it documented somewhere what the individual entries of these vectors
> mean?

You mean, the structure of a timer object?  You will see that clearly
near the beginning of timer.el.

> But anyway, I think even when there's some timer that takes too long,
> the cursor should never disappear completely.  So maybe a redisplay
> should be forced whenever the cursor is set to visible again and there
> has been a redisplay when the cursor has been invisible.

I don't quite understand your idea.  Please keep in mind that there
are 2 meanings to "cursor is [set to] visible": the internal Emacs
information about whether the cursor is on or off, and what's actually
on the glass.  The latter is only changed by redisplay.

With that in mind, can you explain in more detail what you meant?

bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> Is it documented somewhere what the individual entries of these vectors
>> mean?
>
> You mean, the structure of a timer object?  You will see that clearly
> near the beginning of timer.el.

Thanks.

>> But anyway, I think even when there's some timer that takes too long,
>> the cursor should never disappear completely.  So maybe a redisplay
>> should be forced whenever the cursor is set to visible again and
>> there has been a redisplay when the cursor has been invisible.
>
> I don't quite understand your idea.  Please keep in mind that there
> are 2 meanings to "cursor is [set to] visible": the internal Emacs
> information about whether the cursor is on or off, and what's actually
> on the glass.  The latter is only changed by redisplay.
>
> With that in mind, can you explain in more detail what you meant?

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.

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))
  ;; Suspend counting blinks when the w32 menu-bar menu is displayed,
  ;; since otherwise menu tooltips will behave erratically.
  (or (and (fboundp 'w32--menu-bar-in-use)
	   (w32--menu-bar-in-use))
      (setq blink-cursor-blinks-done (1+ blink-cursor-blinks-done)))
  ;; Each blink is two calls to this function.
  (when (and (> blink-cursor-blinks 0)
             (<= (* 2 blink-cursor-blinks) blink-cursor-blinks-done))
    (blink-cursor-suspend)
    (add-hook 'post-command-hook 'blink-cursor-check)))
--8<---------------cut here---------------end--------------->8---

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.

Bye,
Tassilo

bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: 20285@debbugs.gnu.org
> Date: Fri, 10 Apr 2015 11:28:52 +0200
> 
> 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.

> 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?

> 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?

bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking

[Tassilo Horn]

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

bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: 20285@debbugs.gnu.org
> Date: Fri, 10 Apr 2015 15:13:49 +0200
> 
> > 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?

Yes, it is.  But the selected window could well change since the last
redisplay, and there are also things like with-selected-window.

bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: 20285@debbugs.gnu.org
> Date: Fri, 10 Apr 2015 15:13:49 +0200
> 
> 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.

Maybe we should have a mechanism to force redisplay once in a while
even if Emacs has something to do, and blink-cursor-mode could then
activate that mechanism.

bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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.
>
> Maybe we should have a mechanism to force redisplay once in a while
> even if Emacs has something to do, and blink-cursor-mode could then
> activate that mechanism.

I can't read your brain but wouldn't it be possible (but unlikely) that
this mechanism always forces a redisplay when the cursor is in the
invisible state?

What I can imagine is `redisplay' having a second optional argument SECS
which would trigger a redisplay only if there hasn't been one in the
last SECS seconds.  Then `blink-cursor-timer-function' could do

  (internal-show-cursor nil (not (internal-show-cursor-p)))
  (when (internal-show-cursor-p)
    (redisplay 'force 2))

so that toggling the cursor to visible again forces a redisplay every 2
seconds.  Then, the worst situation that can occur is a cycle of cursor
invisible for 2 seconds, cursor visible for 0.5 seconds.  But that would
require that the heavy processing always starts after the redisplay
which made the cursor invisible and stops just after the cursor has been
set to visible again.  I guess that's very unlikely.

Bye,
Tassilo

bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: 20285@debbugs.gnu.org
> Date: Fri, 10 Apr 2015 16:13:44 +0200
> 
> > Maybe we should have a mechanism to force redisplay once in a while
> > even if Emacs has something to do, and blink-cursor-mode could then
> > activate that mechanism.
> 
> I can't read your brain but wouldn't it be possible (but unlikely) that
> this mechanism always forces a redisplay when the cursor is in the
> invisible state?

Not if the time interval is chosen as to make the probability of this
low enough.

> What I can imagine is `redisplay' having a second optional argument SECS
> which would trigger a redisplay only if there hasn't been one in the
> last SECS seconds.  Then `blink-cursor-timer-function' could do
> 
>   (internal-show-cursor nil (not (internal-show-cursor-p)))
>   (when (internal-show-cursor-p)
>     (redisplay 'force 2))
> 
> so that toggling the cursor to visible again forces a redisplay every 2
> seconds.  Then, the worst situation that can occur is a cycle of cursor
> invisible for 2 seconds, cursor visible for 0.5 seconds.

The interval should not be an integral multiple of 0.5 sec.

bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking

[Stefan Monnier]

I haven't followed this discussion very closely, but I can't see
anywhere in this thread where we have data that really confirms that the
problem was that redisplay was skipped because of other needed activities.

Have you tried to call `redisplay' explicitly from the
blink-cursor timer?


        Stefan

bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: Eli Zaretskii <eliz@gnu.org>, 20285@debbugs.gnu.org
> Date: Fri, 10 Apr 2015 14:24:45 -0400
> 
> I haven't followed this discussion very closely, but I can't see
> anywhere in this thread where we have data that really confirms that the
> problem was that redisplay was skipped because of other needed activities.

My impression was that the blink-cursor timer doesn't get to run, but
Tassilo says he have seen evidence to the contrary.

When this happens to me, I definitely see the mode line being updated,
while the cursor stays unchanged, either on or off.  But that could be
because redisplay always sees the cursor state at the same value,
i.e. misses the toggle.

bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking

[Tassilo Horn]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> I haven't followed this discussion very closely, but I can't see
> anywhere in this thread where we have data that really confirms that
> the problem was that redisplay was skipped because of other needed
> activities.

I can at least confirm that `blink-cursor-timer-function' runs every 0.5
seconds and toggles the visibility state of the cursor.  When that state
doesn't appear on the screen, then what else can it be except for a
skipped redisplay.

Maybe the interval is 0.8 seconds sometimes when emacs is under heavy
load.  But the timer not being run is definitely not the cause for not
blinking for up to 10 seconds here.

> Have you tried to call `redisplay' explicitly from the blink-cursor
> timer?

Yes, then it blinks fine even under stress.

Bye,
Tassilo

bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> > Maybe we should have a mechanism to force redisplay once in a while
>> > even if Emacs has something to do, and blink-cursor-mode could then
>> > activate that mechanism.
>> 
>> I can't read your brain but wouldn't it be possible (but unlikely)
>> that this mechanism always forces a redisplay when the cursor is in
>> the invisible state?
>
> Not if the time interval is chosen as to make the probability of this
> low enough.

Yes, but what if different things request different redisplay intervals?
E.g., `blink-cursor-mode' requests an interval of 1.25, and some other
thing requests an interval of 1.0?  1.0 is a bad interval for b-c-m's
sake, so that mechanism can't just use the shortest interval.

Bye,
Tassilo

bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking

[Stefan Monnier]

> I can at least confirm that `blink-cursor-timer-function' runs every 0.5
> seconds and toggles the visibility state of the cursor.  When that state
> doesn't appear on the screen, then what else can it be except for a
> skipped redisplay.

Of course, I don't know what it is, but it could be many other things,
such as a successful redisplay which somehow just didn't think the
relevant window needed to be refreshed.
Or a misinterpretation of the state of the cursor?
Or maybe the cursor state is indeed changed, but not in the right window?

> Maybe the interval is 0.8 seconds sometimes when emacs is under heavy
> load.  But the timer not being run is definitely not the cause for not
> blinking for up to 10 seconds here.
>> Have you tried to call `redisplay' explicitly from the blink-cursor
>> timer?
> Yes, then it blinks fine even under stress.

Great, so that would hint at redisplay being skipped, indeed.
Revision 9e77c1b7bcfd0807be7fe67daf73c2320e864309 changed the way we
decide when to skip a redisplay recently.  The change should make us
skip redisplay strictly less often rather than more often, but maybe
there's a problem in that change.

You could also use a pre-redisplay-function to count how many times
redisplay happensin that particular window.


        Stefan

bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking

[Tassilo Horn]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> I can at least confirm that `blink-cursor-timer-function' runs every 0.5
>> seconds and toggles the visibility state of the cursor.  When that state
>> doesn't appear on the screen, then what else can it be except for a
>> skipped redisplay.
>
> Of course, I don't know what it is, but it could be many other things,
> such as a successful redisplay which somehow just didn't think the
> relevant window needed to be refreshed.
> Or a misinterpretation of the state of the cursor?
> Or maybe the cursor state is indeed changed, but not in the right window?

That happens also when there is just one window (except the minibuffer
window).  And when there are more, the cursors in the other windows stay
hollow boxes.  I haven't noticed that one of them disappeared completely
yet.

>> Maybe the interval is 0.8 seconds sometimes when emacs is under heavy
>> load.  But the timer not being run is definitely not the cause for not
>> blinking for up to 10 seconds here.
>>> Have you tried to call `redisplay' explicitly from the blink-cursor
>>> timer?
>> Yes, then it blinks fine even under stress.
>
> Great, so that would hint at redisplay being skipped, indeed.
> Revision 9e77c1b7bcfd0807be7fe67daf73c2320e864309 changed the way we
> decide when to skip a redisplay recently.  The change should make us
> skip redisplay strictly less often rather than more often, but maybe
> there's a problem in that change.
>
> You could also use a pre-redisplay-function to count how many times
> redisplay happensin that particular window.

Ok, I used the following code (add-function because there's already a
pre-redisplay function which I didn't want to replace):

--8<---------------cut here---------------start------------->8---
(defvar th/redisplay-count 0)

(defun th/count-redisplays (windows)
  (when (or (null windows)
            (eq windows t)
            (memq (selected-window) windows))
    (incf th/redisplay-count)))

(add-function :before pre-redisplay-function #'th/count-redisplays)
--8<---------------cut here---------------end--------------->8---

Then I switched to some large latex buffer, did M-: (setq
th/redisplay-count 0), and then started compiling that document to
generate some load.  Then I waited for exactly one minute in which there
has been at least one phase of almost 10 seconds with the cursor being
invisible on the screen before getting the value of th/redisplay-count.

And the value is seven hundred something every time I test.  That's more
than 10 redisplays of the selected window per second!  I didn't do
anything in that one minute so there shouldn't have been a reason for
redisplay to kick in except for the blinking cursor.  And that would
suggest 120 redisplays.

Of course, it's still possible that during the 10 seconds where the
cursor was invisible on the screen there hasn't been a redisplay of the
selected window, but how can I know?

Bye,
Tassilo

bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: 20285@debbugs.gnu.org
> Date: Fri, 10 Apr 2015 22:52:12 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> > Maybe we should have a mechanism to force redisplay once in a while
> >> > even if Emacs has something to do, and blink-cursor-mode could then
> >> > activate that mechanism.
> >> 
> >> I can't read your brain but wouldn't it be possible (but unlikely)
> >> that this mechanism always forces a redisplay when the cursor is in
> >> the invisible state?
> >
> > Not if the time interval is chosen as to make the probability of this
> > low enough.
> 
> Yes, but what if different things request different redisplay intervals?
> E.g., `blink-cursor-mode' requests an interval of 1.25, and some other
> thing requests an interval of 1.0?  1.0 is a bad interval for b-c-m's
> sake, so that mechanism can't just use the shortest interval.

Yes, the shortest interval is indeed not the best policy.  But it's
not the only one that we could use, I think.

bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: Eli Zaretskii <eliz@gnu.org>, 20285@debbugs.gnu.org
> Date: Fri, 10 Apr 2015 17:50:16 -0400
> 
> > I can at least confirm that `blink-cursor-timer-function' runs every 0.5
> > seconds and toggles the visibility state of the cursor.  When that state
> > doesn't appear on the screen, then what else can it be except for a
> > skipped redisplay.
> 
> Of course, I don't know what it is, but it could be many other things,
> such as a successful redisplay which somehow just didn't think the
> relevant window needed to be refreshed.

The change of the cursor blink state explicitly prevents this
redisplay optimization, see line 13634 of xdisp.c.

> Or a misinterpretation of the state of the cursor?

How can that happen?  The state is a simple on/off variable.

> Or maybe the cursor state is indeed changed, but not in the right window?

Then why does this not happen once the initial load of timers' work is
done, i.e. when Emacs is _really_ idle?

> >> Have you tried to call `redisplay' explicitly from the blink-cursor
> >> timer?
> > Yes, then it blinks fine even under stress.
> 
> Great, so that would hint at redisplay being skipped, indeed.
> Revision 9e77c1b7bcfd0807be7fe67daf73c2320e864309 changed the way we
> decide when to skip a redisplay recently.  The change should make us
> skip redisplay strictly less often rather than more often, but maybe
> there's a problem in that change.

Unlikely, since I see the problem since Emacs 24.4 at least.

bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  20285@debbugs.gnu.org
> Date: Sat, 11 Apr 2015 07:54:52 +0200
> 
> Ok, I used the following code (add-function because there's already a
> pre-redisplay function which I didn't want to replace):
> 
> --8<---------------cut here---------------start------------->8---
> (defvar th/redisplay-count 0)
> 
> (defun th/count-redisplays (windows)
>   (when (or (null windows)
>             (eq windows t)
>             (memq (selected-window) windows))
>     (incf th/redisplay-count)))
> 
> (add-function :before pre-redisplay-function #'th/count-redisplays)
> --8<---------------cut here---------------end--------------->8---
> 
> Then I switched to some large latex buffer, did M-: (setq
> th/redisplay-count 0), and then started compiling that document to
> generate some load.  Then I waited for exactly one minute in which there
> has been at least one phase of almost 10 seconds with the cursor being
> invisible on the screen before getting the value of th/redisplay-count.
> 
> And the value is seven hundred something every time I test.  That's more
> than 10 redisplays of the selected window per second!  I didn't do
> anything in that one minute so there shouldn't have been a reason for
> redisplay to kick in except for the blinking cursor.  And that would
> suggest 120 redisplays.

Can you please elaborate as to how you arrived to these numbers?  I
fail to follow your line of reasoning; perhaps it's too early and I
don't yet have enough caffeine in my blood.  E.g., how do you deduce
from "seven hundred something" that there were more than 10 redisplays
per second?

> Of course, it's still possible that during the 10 seconds where the
> cursor was invisible on the screen there hasn't been a redisplay of the
> selected window, but how can I know?

If your Emacs is configured with --enable-checking='yes,glyphs', then
you can invoke "M-x trace-redisplay RET", and see every entry to
redisplay_internal announced on stderr.

bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking

[Eli Zaretskii]

> Date: Sat, 11 Apr 2015 10:34:23 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 20285@debbugs.gnu.org
> 
> > Of course, it's still possible that during the 10 seconds where the
> > cursor was invisible on the screen there hasn't been a redisplay of the
> > selected window, but how can I know?
> 
> If your Emacs is configured with --enable-checking='yes,glyphs', then
> you can invoke "M-x trace-redisplay RET", and see every entry to
> redisplay_internal announced on stderr.

After building Emacs 24.5 and observing the same issue there, I've
decided to try to set blink-cursor-interval to something that is not
an integer divider of 1 sec.  So I set it to 0.53 sec, and lo and
behold, the problem disappeared: the cursor blinks and blinks, and
never stops blinking, even when there's JIT Stealth working in the
background, as well as other stuff, as always in my sessions.

So I think at least what I observed is somehow related to the specific
value of 0.5 sec.  Perhaps some other timer of other periodic activity
(auto-save?) that runs at an integral multiple of 0.5 sec gets in the
way somehow.  E.g., it could toggle the cursor twice before the next
redisplay cycle.  Or something.

bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> Then I switched to some large latex buffer, did M-: (setq
>> th/redisplay-count 0), and then started compiling that document to
>> generate some load.  Then I waited for exactly one minute in which there
>> has been at least one phase of almost 10 seconds with the cursor being
>> invisible on the screen before getting the value of th/redisplay-count.
>> 
>> And the value is seven hundred something every time I test.  That's more
>> than 10 redisplays of the selected window per second!  I didn't do
>> anything in that one minute so there shouldn't have been a reason for
>> redisplay to kick in except for the blinking cursor.  And that would
>> suggest 120 redisplays.
>
> Can you please elaborate as to how you arrived to these numbers?  I
> fail to follow your line of reasoning; perhaps it's too early and I
> don't yet have enough caffeine in my blood.  E.g., how do you deduce
> from "seven hundred something" that there were more than 10 redisplays
> per second?

Well, I set the counter to zero and then measured ~60 seconds.  In that
time, there were 783 redisplays IIRC.  That gives an average of 13.05
redisplays per second.

>> Of course, it's still possible that during the 10 seconds where the
>> cursor was invisible on the screen there hasn't been a redisplay of
>> the selected window, but how can I know?
>
> If your Emacs is configured with --enable-checking='yes,glyphs', then
> you can invoke "M-x trace-redisplay RET", and see every entry to
> redisplay_internal announced on stderr.

Ok, I'll try that out.  I'll also try out the 0.53 interval to check if
that cures the issue for me, too.

Bye,
Tassilo

bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking

[Tassilo Horn]

Tassilo Horn <tsdh@gnu.org> writes:

>> If your Emacs is configured with --enable-checking='yes,glyphs', then
>> you can invoke "M-x trace-redisplay RET", and see every entry to
>> redisplay_internal announced on stderr.
>
> Ok, I'll try that out.

Done that now and got output like

redisplay_preserve_echo_area (12)
redisplay_internal 0
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (12)
redisplay_internal 0
redisplay_internal 0
redisplay_preserve_echo_area (12)
redisplay_internal 0
redisplay_internal 0

In general, I've been amazed how often redisplay is performed even
though nothing has changed in neither the single window containing the
buffer with my latex doc nor the minibuffer.  Ten times a second is very
likely, maybe even more.

Then I compiled my latex doc to generate some stress.  Every compile
takes about a good minute.  That used to work without blinking
interruption at least four times, but with the fifth time, out of
sudden, it stuck after

  redisplay_internal 0

and would not start anymore until my latex document was compiled and
AUCTeX echoed "LaTeX: successfully formatted {293} pages".  That seems
to have triggered the resume of redisplay.
The redisplay pause was at least 20 to 30 seconds.

Bye,
Tassilo

bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking

[Stefan Monnier]

> Well, I set the counter to zero and then measured ~60 seconds.  In that
> time, there were 783 redisplays IIRC.  That gives an average of 13.05
> redisplays per second.

If you had a latex subprocess running, every chunk of output received
via the process filter probably caused a call to redisplay.

> Ok, I'll try that out.  I'll also try out the 0.53 interval to check if
> that cures the issue for me, too.

How 'bout something smaller than 0.5 (e.g. 0.45)?


        Stefan

bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking

[Tassilo Horn]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> Well, I set the counter to zero and then measured ~60 seconds.  In
>> that time, there were 783 redisplays IIRC.  That gives an average of
>> 13.05 redisplays per second.
>
> If you had a latex subprocess running, every chunk of output received
> via the process filter probably caused a call to redisplay.

That would explain things.  But why does that trigger a redisplay?  The
buffer receiving the output hasn't been displayed in a window.

>> Ok, I'll try that out.  I'll also try out the 0.53 interval to check if
>> that cures the issue for me, too.
>
> How 'bout something smaller than 0.5 (e.g. 0.45)?

I've tried both 0.53 and 0.45 and haven't been able to reproduce the
hang.  But I haven't tested long enough to tell if that really solves
the issue.

Bye,
Tassilo

bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: monnier@IRO.UMontreal.CA,  20285@debbugs.gnu.org
> Date: Sat, 11 Apr 2015 14:39:45 +0200
> 
> Tassilo Horn <tsdh@gnu.org> writes:
> 
> >> If your Emacs is configured with --enable-checking='yes,glyphs', then
> >> you can invoke "M-x trace-redisplay RET", and see every entry to
> >> redisplay_internal announced on stderr.
> >
> > Ok, I'll try that out.
> 
> Done that now and got output like
> 
> redisplay_preserve_echo_area (12)
> redisplay_internal 0
> redisplay_internal 0
> redisplay_preserve_echo_area (8)
> redisplay_internal 0
> redisplay_preserve_echo_area (12)
> redisplay_internal 0
> redisplay_internal 0
> redisplay_preserve_echo_area (12)
> redisplay_internal 0
> redisplay_internal 0

That's what you should get; each "redisplay_internal 0" line is an
entry to redisplay.

> In general, I've been amazed how often redisplay is performed even
> though nothing has changed in neither the single window containing the
> buffer with my latex doc nor the minibuffer.  Ten times a second is very
> likely, maybe even more.

Really?  Is that in "emacs -Q"?  I get only 20 entries to redisplay,
every 0.5 sec, one each for every toggle of the blinking cursor, and
after those it stops.

I can only understand a much more frequent redisplay if you have a lot
of timers, or a high-frequency timer.  When a timer fires, we call
redisplay, AFAIR.

> Then I compiled my latex doc to generate some stress.  Every compile
> takes about a good minute.  That used to work without blinking
> interruption at least four times, but with the fifth time, out of
> sudden, it stuck after
> 
>   redisplay_internal 0

I'm guessing that your LaTeX compilation is via "M-x compile" or a
similar async subprocess.  If so, whether or not redisplay is called
depends on the speed the compilation process emits stuff that Emacs
reads.  If the subprocess outputs a lot of stuff, it will have the
same effect as high-speed keyboard input -- in both cases Emacs will
not enter redisplay until it's idle.

> and would not start anymore until my latex document was compiled and
> AUCTeX echoed "LaTeX: successfully formatted {293} pages".  That seems
> to have triggered the resume of redisplay.

Displaying an echo area message triggers redisplay.

> The redisplay pause was at least 20 to 30 seconds.

If there's no redisplay, you won't see the cursor blink.

bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  20285@debbugs.gnu.org
> Date: Sat, 11 Apr 2015 16:30:06 +0200
> 
> > How 'bout something smaller than 0.5 (e.g. 0.45)?
> 
> I've tried both 0.53 and 0.45 and haven't been able to reproduce the
> hang.  But I haven't tested long enough to tell if that really solves
> the issue.

0.47 works here (I prefer it to 0.45, which is too "round", and might
easily resonate with something like 9 sec period).

bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  20285@debbugs.gnu.org
> Date: Sat, 11 Apr 2015 16:30:06 +0200
> 
> > If you had a latex subprocess running, every chunk of output received
> > via the process filter probably caused a call to redisplay.
> 
> That would explain things.  But why does that trigger a redisplay?  The
> buffer receiving the output hasn't been displayed in a window.

The arrival of subprocess output causes the pselect call to return,
marking the file descriptor for that process ready to be read.  Emacs
then reads from the descriptor, and returns to the idle loop.  If by
that time no additional process output arrived, Emacs will enter
redisplay.

IOW, arrival of process output is an event that causes the main loop
to crank one more time, and that includes redisplay.

bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> In general, I've been amazed how often redisplay is performed even
>> though nothing has changed in neither the single window containing the
>> buffer with my latex doc nor the minibuffer.  Ten times a second is very
>> likely, maybe even more.
>
> Really?  Is that in "emacs -Q"?  I get only 20 entries to redisplay,
> every 0.5 sec, one each for every toggle of the blinking cursor, and
> after those it stops.

No, its emacs as I use it daily, that is, with a lot of timers from Gnus
and rcirc, and process filters from AUCTeX, etc.  With emacs -Q I
haven't been able to reproduce the issue.

> I can only understand a much more frequent redisplay if you have a lot
> of timers, or a high-frequency timer.  When a timer fires, we call
> redisplay, AFAIR.

I have a lot of timers but they aren't too high frequency.  But I think
Stefan's explanation (which is the same as you write below) is correct,
i.e., a redisplay is triggered by new output received from the async
latex compile process.

>> Then I compiled my latex doc to generate some stress.  Every compile
>> takes about a good minute.  That used to work without blinking
>> interruption at least four times, but with the fifth time, out of
>> sudden, it stuck after
>> 
>>   redisplay_internal 0
>
> I'm guessing that your LaTeX compilation is via "M-x compile" or a
> similar async subprocess.

Yes, AUCTeX starts it with `start-process' and puts a process filter on
it.

> If so, whether or not redisplay is called depends on the speed the
> compilation process emits stuff that Emacs reads.  If the subprocess
> outputs a lot of stuff,

Yes, with the document I'm using for testing, the latex process emits
4000 lines of text in about a 40 seconds.

> it will have the same effect as high-speed keyboard input -- in both
> cases Emacs will not enter redisplay until it's idle.

It seems that up to some point, the frequent arrival of input triggers a
lot of redisplays, just as you explain in your other mail:

,----
| The arrival of subprocess output causes the pselect call to return,
| marking the file descriptor for that process ready to be read.  Emacs
| then reads from the descriptor, and returns to the idle loop.  If by
| that time no additional process output arrived, Emacs will enter
| redisplay.
| 
| IOW, arrival of process output is an event that causes the main loop
| to crank one more time, and that includes redisplay.
`----

But under some circumstances which aren't completely clear to me, the
subprocess output paired with timers etc can cause a redisplay pause.
The even default interval of 0.5 of b-c-m seems to play its role
thereby.

>> and would not start anymore until my latex document was compiled and
>> AUCTeX echoed "LaTeX: successfully formatted {293} pages".  That
>> seems to have triggered the resume of redisplay.
>
> Displaying an echo area message triggers redisplay.
>
>> The redisplay pause was at least 20 to 30 seconds.
>
> If there's no redisplay, you won't see the cursor blink.

Of course.

Bye,
Tassilo

bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: monnier@IRO.UMontreal.CA,  20285@debbugs.gnu.org
> Date: Sat, 11 Apr 2015 21:24:18 +0200
> 
> > I can only understand a much more frequent redisplay if you have a lot
> > of timers, or a high-frequency timer.  When a timer fires, we call
> > redisplay, AFAIR.
> 
> I have a lot of timers but they aren't too high frequency.

They could be if taken together.

> But I think Stefan's explanation (which is the same as you write
> below) is correct, i.e., a redisplay is triggered by new output
> received from the async latex compile process.

It is triggered if there's a small time window between two successive
chunks of subprocess output, so that Emacs has enough time to return
to the idle loop and see that no new input is available.

> > If so, whether or not redisplay is called depends on the speed the
> > compilation process emits stuff that Emacs reads.  If the subprocess
> > outputs a lot of stuff,
> 
> Yes, with the document I'm using for testing, the latex process emits
> 4000 lines of text in about a 40 seconds.

The fine timing of this output's chunks is important.

> It seems that up to some point, the frequent arrival of input triggers a
> lot of redisplays, just as you explain in your other mail:
> 
> ,----
> | The arrival of subprocess output causes the pselect call to return,
> | marking the file descriptor for that process ready to be read.  Emacs
> | then reads from the descriptor, and returns to the idle loop.  If by
> | that time no additional process output arrived, Emacs will enter
> | redisplay.
> | 
> | IOW, arrival of process output is an event that causes the main loop
> | to crank one more time, and that includes redisplay.
> `----
> 
> But under some circumstances which aren't completely clear to me, the
> subprocess output paired with timers etc can cause a redisplay pause.
> The even default interval of 0.5 of b-c-m seems to play its role
> thereby.

This could happen if a very large chunk of output arrives, or several
smaller chunks arrive with almost no delay between them.  Then Emacs
will not become idle before it sees that more input is available.

bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> But I think Stefan's explanation (which is the same as you write
>> below) is correct, i.e., a redisplay is triggered by new output
>> received from the async latex compile process.
>
> It is triggered if there's a small time window between two successive
> chunks of subprocess output, so that Emacs has enough time to return
> to the idle loop and see that no new input is available.

I see.

>> But under some circumstances which aren't completely clear to me, the
>> subprocess output paired with timers etc can cause a redisplay pause.
>> The even default interval of 0.5 of b-c-m seems to play its role
>> thereby.
>
> This could happen if a very large chunk of output arrives, or several
> smaller chunks arrive with almost no delay between them.  Then Emacs
> will not become idle before it sees that more input is available.

Yes, with this specific latex document, there are hundreds of small
chunks arriving in almost no time.

Bye,
Tassilo

bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking

[Stefan Monnier]

> That would explain things.  But why does that trigger a redisplay?  The
> buffer receiving the output hasn't been displayed in a window.

It's redisplay's role to figure out that nothing has changed.  I don't
know how much work redisplay will do in your case.


        Stefan

bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking

[Lars Ingebrigtsen]

Tassilo Horn <tsdh@gnu.org> writes:

> Sometimes it occurs to me that `blink-cursor-mode' stops blinking the
> cursor for some time.  That temporary stop might also occur in the
> off-phase so that there's no visible cursor anymore.  As soon as I press
> some key, the blinking starts again.  But just now in some specific
> buffer, it'll blink twice and then disappear until I press a key again.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

I'm unable to reproduce this issue in Emacs 29.  Do you still see this
problem in recent Emacs versions?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking

[Tassilo Horn]

Lars Ingebrigtsen <larsi@gnus.org> writes:

Hi Lars,

>> Sometimes it occurs to me that `blink-cursor-mode' stops blinking the
>> cursor for some time.  That temporary stop might also occur in the
>> off-phase so that there's no visible cursor anymore.  As soon as I press
>> some key, the blinking starts again.  But just now in some specific
>> buffer, it'll blink twice and then disappear until I press a key again.
>
> (I'm going through old bug reports that unfortunately weren't resolved
> at the time.)
>
> I'm unable to reproduce this issue in Emacs 29.  Do you still see this
> problem in recent Emacs versions?

No, I don't think so.  Feel free to close the report.

Bye,
Tassilo

bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking

[Lars Ingebrigtsen]

Tassilo Horn <tsdh@gnu.org> writes:

> No, I don't think so.  Feel free to close the report.

Thanks for checking; I'm closing this bug report, then.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no