* bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking @ 2015-04-09 14:50 Tassilo Horn 2015-04-09 15:06 ` Eli Zaretskii 2022-04-28 10:50 ` Lars Ingebrigtsen 0 siblings, 2 replies; 36+ messages in thread From: Tassilo Horn @ 2015-04-09 14:50 UTC (permalink / raw) To: 20285 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)) ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking 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 2022-04-28 10:50 ` Lars Ingebrigtsen 1 sibling, 1 reply; 36+ messages in thread From: Eli Zaretskii @ 2015-04-09 15:06 UTC (permalink / raw) To: Tassilo Horn; +Cc: 20285 > 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. ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking 2015-04-09 15:06 ` Eli Zaretskii @ 2015-04-09 16:07 ` Eli Zaretskii 2015-04-10 7:46 ` Tassilo Horn 0 siblings, 1 reply; 36+ messages in thread From: Eli Zaretskii @ 2015-04-09 16:07 UTC (permalink / raw) To: tsdh; +Cc: 20285 > 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" ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking 2015-04-09 16:07 ` Eli Zaretskii @ 2015-04-10 7:46 ` Tassilo Horn 2015-04-10 7:58 ` Eli Zaretskii 0 siblings, 1 reply; 36+ messages in thread From: Tassilo Horn @ 2015-04-10 7:46 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 20285 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking 2015-04-10 7:46 ` Tassilo Horn @ 2015-04-10 7:58 ` Eli Zaretskii 2015-04-10 9:28 ` Tassilo Horn 0 siblings, 1 reply; 36+ messages in thread From: Eli Zaretskii @ 2015-04-10 7:58 UTC (permalink / raw) To: Tassilo Horn; +Cc: 20285 > 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? ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking 2015-04-10 7:58 ` Eli Zaretskii @ 2015-04-10 9:28 ` Tassilo Horn 2015-04-10 12:42 ` Eli Zaretskii 0 siblings, 1 reply; 36+ messages in thread From: Tassilo Horn @ 2015-04-10 9:28 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 20285 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking 2015-04-10 9:28 ` Tassilo Horn @ 2015-04-10 12:42 ` Eli Zaretskii 2015-04-10 13:13 ` Tassilo Horn 0 siblings, 1 reply; 36+ messages in thread From: Eli Zaretskii @ 2015-04-10 12:42 UTC (permalink / raw) To: Tassilo Horn; +Cc: 20285 > 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? ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking 2015-04-10 12:42 ` Eli Zaretskii @ 2015-04-10 13:13 ` Tassilo Horn 2015-04-10 13:28 ` Eli Zaretskii 2015-04-10 13:32 ` Eli Zaretskii 0 siblings, 2 replies; 36+ messages in thread From: Tassilo Horn @ 2015-04-10 13:13 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 20285 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking 2015-04-10 13:13 ` Tassilo Horn @ 2015-04-10 13:28 ` Eli Zaretskii 2015-04-10 13:32 ` Eli Zaretskii 1 sibling, 0 replies; 36+ messages in thread From: Eli Zaretskii @ 2015-04-10 13:28 UTC (permalink / raw) To: Tassilo Horn; +Cc: 20285 > 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. ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking 2015-04-10 13:13 ` Tassilo Horn 2015-04-10 13:28 ` Eli Zaretskii @ 2015-04-10 13:32 ` Eli Zaretskii 2015-04-10 14:13 ` Tassilo Horn 1 sibling, 1 reply; 36+ messages in thread From: Eli Zaretskii @ 2015-04-10 13:32 UTC (permalink / raw) To: Tassilo Horn; +Cc: 20285 > 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. ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking 2015-04-10 13:32 ` Eli Zaretskii @ 2015-04-10 14:13 ` Tassilo Horn 2015-04-10 17:32 ` Eli Zaretskii 2015-04-10 18:24 ` Stefan Monnier 0 siblings, 2 replies; 36+ messages in thread From: Tassilo Horn @ 2015-04-10 14:13 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 20285 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking 2015-04-10 14:13 ` Tassilo Horn @ 2015-04-10 17:32 ` Eli Zaretskii 2015-04-10 20:52 ` Tassilo Horn 2015-04-10 18:24 ` Stefan Monnier 1 sibling, 1 reply; 36+ messages in thread From: Eli Zaretskii @ 2015-04-10 17:32 UTC (permalink / raw) To: Tassilo Horn; +Cc: 20285 > 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. ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking 2015-04-10 17:32 ` Eli Zaretskii @ 2015-04-10 20:52 ` Tassilo Horn 2015-04-11 6:25 ` Eli Zaretskii 0 siblings, 1 reply; 36+ messages in thread From: Tassilo Horn @ 2015-04-10 20:52 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 20285 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking 2015-04-10 20:52 ` Tassilo Horn @ 2015-04-11 6:25 ` Eli Zaretskii 0 siblings, 0 replies; 36+ messages in thread From: Eli Zaretskii @ 2015-04-11 6:25 UTC (permalink / raw) To: Tassilo Horn; +Cc: 20285 > 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. ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking 2015-04-10 14:13 ` Tassilo Horn 2015-04-10 17:32 ` Eli Zaretskii @ 2015-04-10 18:24 ` Stefan Monnier 2015-04-10 18:42 ` Eli Zaretskii 2015-04-10 20:21 ` Tassilo Horn 1 sibling, 2 replies; 36+ messages in thread From: Stefan Monnier @ 2015-04-10 18:24 UTC (permalink / raw) To: Tassilo Horn; +Cc: 20285 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking 2015-04-10 18:24 ` Stefan Monnier @ 2015-04-10 18:42 ` Eli Zaretskii 2015-04-10 20:21 ` Tassilo Horn 1 sibling, 0 replies; 36+ messages in thread From: Eli Zaretskii @ 2015-04-10 18:42 UTC (permalink / raw) To: Stefan Monnier; +Cc: 20285, tsdh > 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. ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking 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 1 sibling, 1 reply; 36+ messages in thread From: Tassilo Horn @ 2015-04-10 20:21 UTC (permalink / raw) To: Stefan Monnier; +Cc: 20285 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking 2015-04-10 20:21 ` Tassilo Horn @ 2015-04-10 21:50 ` Stefan Monnier 2015-04-11 5:54 ` Tassilo Horn 2015-04-11 6:30 ` Eli Zaretskii 0 siblings, 2 replies; 36+ messages in thread From: Stefan Monnier @ 2015-04-10 21:50 UTC (permalink / raw) To: Tassilo Horn; +Cc: 20285 > 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking 2015-04-10 21:50 ` Stefan Monnier @ 2015-04-11 5:54 ` Tassilo Horn 2015-04-11 7:34 ` Eli Zaretskii 2015-04-11 6:30 ` Eli Zaretskii 1 sibling, 1 reply; 36+ messages in thread From: Tassilo Horn @ 2015-04-11 5:54 UTC (permalink / raw) To: Stefan Monnier; +Cc: 20285 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking 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 0 siblings, 2 replies; 36+ messages in thread From: Eli Zaretskii @ 2015-04-11 7:34 UTC (permalink / raw) To: Tassilo Horn; +Cc: 20285 > 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. ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking 2015-04-11 7:34 ` Eli Zaretskii @ 2015-04-11 11:34 ` Eli Zaretskii 2015-04-11 11:49 ` Tassilo Horn 1 sibling, 0 replies; 36+ messages in thread From: Eli Zaretskii @ 2015-04-11 11:34 UTC (permalink / raw) To: tsdh; +Cc: 20285 > 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. ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking 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:02 ` Stefan Monnier 1 sibling, 2 replies; 36+ messages in thread From: Tassilo Horn @ 2015-04-11 11:49 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 20285 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking 2015-04-11 11:49 ` Tassilo Horn @ 2015-04-11 12:39 ` Tassilo Horn 2015-04-11 14:45 ` Eli Zaretskii 2015-04-11 14:02 ` Stefan Monnier 1 sibling, 1 reply; 36+ messages in thread From: Tassilo Horn @ 2015-04-11 12:39 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 20285 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking 2015-04-11 12:39 ` Tassilo Horn @ 2015-04-11 14:45 ` Eli Zaretskii 2015-04-11 19:24 ` Tassilo Horn 0 siblings, 1 reply; 36+ messages in thread From: Eli Zaretskii @ 2015-04-11 14:45 UTC (permalink / raw) To: Tassilo Horn; +Cc: 20285 > 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. ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking 2015-04-11 14:45 ` Eli Zaretskii @ 2015-04-11 19:24 ` Tassilo Horn 2015-04-11 19:45 ` Eli Zaretskii 0 siblings, 1 reply; 36+ messages in thread From: Tassilo Horn @ 2015-04-11 19:24 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 20285 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking 2015-04-11 19:24 ` Tassilo Horn @ 2015-04-11 19:45 ` Eli Zaretskii 2015-04-11 20:17 ` Tassilo Horn 0 siblings, 1 reply; 36+ messages in thread From: Eli Zaretskii @ 2015-04-11 19:45 UTC (permalink / raw) To: Tassilo Horn; +Cc: 20285 > 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. ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking 2015-04-11 19:45 ` Eli Zaretskii @ 2015-04-11 20:17 ` Tassilo Horn 0 siblings, 0 replies; 36+ messages in thread From: Tassilo Horn @ 2015-04-11 20:17 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 20285 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking 2015-04-11 11:49 ` Tassilo Horn 2015-04-11 12:39 ` Tassilo Horn @ 2015-04-11 14:02 ` Stefan Monnier 2015-04-11 14:30 ` Tassilo Horn 1 sibling, 1 reply; 36+ messages in thread From: Stefan Monnier @ 2015-04-11 14:02 UTC (permalink / raw) To: Tassilo Horn; +Cc: 20285 > 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking 2015-04-11 14:02 ` Stefan Monnier @ 2015-04-11 14:30 ` Tassilo Horn 2015-04-11 14:48 ` Eli Zaretskii ` (2 more replies) 0 siblings, 3 replies; 36+ messages in thread From: Tassilo Horn @ 2015-04-11 14:30 UTC (permalink / raw) To: Stefan Monnier; +Cc: 20285 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking 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 2 siblings, 0 replies; 36+ messages in thread From: Eli Zaretskii @ 2015-04-11 14:48 UTC (permalink / raw) To: Tassilo Horn; +Cc: 20285 > 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). ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking 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 2 siblings, 0 replies; 36+ messages in thread From: Eli Zaretskii @ 2015-04-11 15:14 UTC (permalink / raw) To: Tassilo Horn; +Cc: 20285 > 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. ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking 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 2 siblings, 0 replies; 36+ messages in thread From: Stefan Monnier @ 2015-04-12 4:05 UTC (permalink / raw) To: Tassilo Horn; +Cc: 20285 > 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking 2015-04-10 21:50 ` Stefan Monnier 2015-04-11 5:54 ` Tassilo Horn @ 2015-04-11 6:30 ` Eli Zaretskii 1 sibling, 0 replies; 36+ messages in thread From: Eli Zaretskii @ 2015-04-11 6:30 UTC (permalink / raw) To: Stefan Monnier; +Cc: 20285, tsdh > 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. ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking 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 @ 2022-04-28 10:50 ` Lars Ingebrigtsen 2022-04-28 11:48 ` Tassilo Horn 1 sibling, 1 reply; 36+ messages in thread From: Lars Ingebrigtsen @ 2022-04-28 10:50 UTC (permalink / raw) To: Tassilo Horn; +Cc: 20285 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking 2022-04-28 10:50 ` Lars Ingebrigtsen @ 2022-04-28 11:48 ` Tassilo Horn 2022-04-28 11:51 ` Lars Ingebrigtsen 0 siblings, 1 reply; 36+ messages in thread From: Tassilo Horn @ 2022-04-28 11:48 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 20285 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking 2022-04-28 11:48 ` Tassilo Horn @ 2022-04-28 11:51 ` Lars Ingebrigtsen 0 siblings, 0 replies; 36+ messages in thread From: Lars Ingebrigtsen @ 2022-04-28 11:51 UTC (permalink / raw) To: Tassilo Horn; +Cc: 20285 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 ^ permalink raw reply [flat|nested] 36+ messages in thread
end of thread, other threads:[~2022-04-28 11:51 UTC | newest] Thread overview: 36+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 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
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).