From unknown Sun Jun 22 08:03:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking Resent-From: Tassilo Horn Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Apr 2015 14:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 20285 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 20285@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.142859108415092 (code B ref -1); Thu, 09 Apr 2015 14:52:02 +0000 Received: (at submit) by debbugs.gnu.org; 9 Apr 2015 14:51:24 +0000 Received: from localhost ([127.0.0.1]:51260 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgDne-0003vJ-HV for submit@debbugs.gnu.org; Thu, 09 Apr 2015 10:51:24 -0400 Received: from eggs.gnu.org ([208.118.235.92]:55651) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgDnb-0003v2-9H for submit@debbugs.gnu.org; Thu, 09 Apr 2015 10:51:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YgDnR-0003Xw-QT for submit@debbugs.gnu.org; Thu, 09 Apr 2015 10:51:14 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:35420) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YgDnR-0003Xr-N6 for submit@debbugs.gnu.org; Thu, 09 Apr 2015 10:51:09 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40799) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YgDnK-000166-Qu for bug-gnu-emacs@gnu.org; Thu, 09 Apr 2015 10:51:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YgDnG-0003U7-6Y for bug-gnu-emacs@gnu.org; Thu, 09 Apr 2015 10:51:02 -0400 Received: from deliver.uni-koblenz.de ([141.26.64.15]:40824) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YgDnF-0003Tx-KC for bug-gnu-emacs@gnu.org; Thu, 09 Apr 2015 10:50:57 -0400 Received: from thinkpad-t440p (dhcp236.uni-koblenz.de [141.26.71.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by deliver.uni-koblenz.de (Postfix) with ESMTPSA id B904D1A8429 for ; Thu, 9 Apr 2015 16:50:56 +0200 (CEST) From: Tassilo Horn Date: Thu, 09 Apr 2015 16:50:56 +0200 Message-ID: <8761954apb.fsf@gnu.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) 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)) From unknown Sun Jun 22 08:03:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Apr 2015 15:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20285 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Tassilo Horn Cc: 20285@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 20285-submit@debbugs.gnu.org id=B20285.142859195922254 (code B ref 20285); Thu, 09 Apr 2015 15:06:02 +0000 Received: (at 20285) by debbugs.gnu.org; 9 Apr 2015 15:05:59 +0000 Received: from localhost ([127.0.0.1]:51291 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgE1m-0005ms-OX for submit@debbugs.gnu.org; Thu, 09 Apr 2015 11:05:59 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:41101) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgE1j-0005mT-Tk for 20285@debbugs.gnu.org; Thu, 09 Apr 2015 11:05:57 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NMJ00B00OEW1000@a-mtaout22.012.net.il> for 20285@debbugs.gnu.org; Thu, 09 Apr 2015 18:05:48 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NMJ00BPKOLN1900@a-mtaout22.012.net.il>; Thu, 09 Apr 2015 18:05:48 +0300 (IDT) Date: Thu, 09 Apr 2015 18:06:01 +0300 From: Eli Zaretskii In-reply-to: <8761954apb.fsf@gnu.org> X-012-Sender: halo1@inter.net.il Message-id: <831tjtfijq.fsf@gnu.org> References: <8761954apb.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Tassilo Horn > 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. From unknown Sun Jun 22 08:03:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Apr 2015 16:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20285 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: tsdh@gnu.org Cc: 20285@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 20285-submit@debbugs.gnu.org id=B20285.14285956652013 (code B ref 20285); Thu, 09 Apr 2015 16:08:02 +0000 Received: (at 20285) by debbugs.gnu.org; 9 Apr 2015 16:07:45 +0000 Received: from localhost ([127.0.0.1]:51335 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgEzV-0000WF-PW for submit@debbugs.gnu.org; Thu, 09 Apr 2015 12:07:45 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:36242) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgEzQ-0000Vu-FR for 20285@debbugs.gnu.org; Thu, 09 Apr 2015 12:07:40 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NMJ00000QXQ9400@a-mtaout20.012.net.il> for 20285@debbugs.gnu.org; Thu, 09 Apr 2015 19:07:29 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NMJ0003RRGH9C20@a-mtaout20.012.net.il>; Thu, 09 Apr 2015 19:07:29 +0300 (IDT) Date: Thu, 09 Apr 2015 19:07:42 +0300 From: Eli Zaretskii In-reply-to: <831tjtfijq.fsf@gnu.org> X-012-Sender: halo1@inter.net.il Message-id: <83zj6he14h.fsf@gnu.org> References: <8761954apb.fsf@gnu.org> <831tjtfijq.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Thu, 09 Apr 2015 18:06:01 +0300 > From: Eli Zaretskii > Cc: 20285@debbugs.gnu.org > > > From: Tassilo Horn > > 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" From unknown Sun Jun 22 08:03:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking Resent-From: Tassilo Horn Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 10 Apr 2015 07:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20285 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 20285@debbugs.gnu.org Received: via spool by 20285-submit@debbugs.gnu.org id=B20285.142865201318957 (code B ref 20285); Fri, 10 Apr 2015 07:47:02 +0000 Received: (at 20285) by debbugs.gnu.org; 10 Apr 2015 07:46:53 +0000 Received: from localhost ([127.0.0.1]:51769 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgTeO-0004vg-UY for submit@debbugs.gnu.org; Fri, 10 Apr 2015 03:46:53 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:50444) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgTeN-0004vV-73 for 20285@debbugs.gnu.org; Fri, 10 Apr 2015 03:46:51 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 5CED1208A1 for <20285@debbugs.gnu.org>; Fri, 10 Apr 2015 03:46:46 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Fri, 10 Apr 2015 03:46:50 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=bF1UPtOQ/p/TT6C I0+PBTxboSU8=; b=C4GI67qvM8HDGAsRs0mRMg/Gai3agVlHj5UJi+eaO564p3r tmpwuQaOzCQIkkOK4sYF4rTAQY02Gy3z1s2Ct+MQgHX2hRtegStCaJvRq9xrhp7S TpNJYT/gnApOTLNhEvyESInADcCN6sdcT1ss7UWMpZ7wo+iqcO5A9fMvNHdY= X-Sasl-enc: WXujU6RZfc8M9VQ/33ezyDOXQaSJPGMyCPHT45WT2B/t 1428652009 Received: from thinkpad-t440p (unknown [2.163.240.161]) by mail.messagingengine.com (Postfix) with ESMTPA id 71E95C00015; Fri, 10 Apr 2015 03:46:49 -0400 (EDT) From: Tassilo Horn References: <8761954apb.fsf@gnu.org> <831tjtfijq.fsf@gnu.org> <83zj6he14h.fsf@gnu.org> Date: Fri, 10 Apr 2015 09:46:46 +0200 In-Reply-To: <83zj6he14h.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 09 Apr 2015 19:07:42 +0300") Message-ID: <87wq1kmnmh.fsf@gnu.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Eli Zaretskii 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 "\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 | (#) | 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 From unknown Sun Jun 22 08:03:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 10 Apr 2015 07:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20285 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Tassilo Horn Cc: 20285@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 20285-submit@debbugs.gnu.org id=B20285.142865272120242 (code B ref 20285); Fri, 10 Apr 2015 07:59:02 +0000 Received: (at 20285) by debbugs.gnu.org; 10 Apr 2015 07:58:41 +0000 Received: from localhost ([127.0.0.1]:51773 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgTpp-0005GO-81 for submit@debbugs.gnu.org; Fri, 10 Apr 2015 03:58:41 -0400 Received: from mtaout29.012.net.il ([80.179.55.185]:50401) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgTpn-0005G4-3c for 20285@debbugs.gnu.org; Fri, 10 Apr 2015 03:58:40 -0400 Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NMK00L00ZAOEM00@mtaout29.012.net.il> for 20285@debbugs.gnu.org; Fri, 10 Apr 2015 10:56:20 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NMK00LH3ZDW9G00@mtaout29.012.net.il>; Fri, 10 Apr 2015 10:56:20 +0300 (IDT) Date: Fri, 10 Apr 2015 10:58:32 +0300 From: Eli Zaretskii In-reply-to: <87wq1kmnmh.fsf@gnu.org> X-012-Sender: halo1@inter.net.il Message-id: <83d23cv2hj.fsf@gnu.org> References: <8761954apb.fsf@gnu.org> <831tjtfijq.fsf@gnu.org> <83zj6he14h.fsf@gnu.org> <87wq1kmnmh.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Tassilo Horn > 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 "\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 > | (#) > | 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? From unknown Sun Jun 22 08:03:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking Resent-From: Tassilo Horn Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 10 Apr 2015 09:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20285 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 20285@debbugs.gnu.org Received: via spool by 20285-submit@debbugs.gnu.org id=B20285.142865814129544 (code B ref 20285); Fri, 10 Apr 2015 09:29:01 +0000 Received: (at 20285) by debbugs.gnu.org; 10 Apr 2015 09:29:01 +0000 Received: from localhost ([127.0.0.1]:51836 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgVFE-0007gP-8D for submit@debbugs.gnu.org; Fri, 10 Apr 2015 05:29:00 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:52541) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgVFA-0007gF-Hi for 20285@debbugs.gnu.org; Fri, 10 Apr 2015 05:28:58 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 2578120650 for <20285@debbugs.gnu.org>; Fri, 10 Apr 2015 05:28:52 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Fri, 10 Apr 2015 05:28:56 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=ZzH43kbXCg3zzQzt3+l3sXGud84=; b=dcKwV cZCltTPK03OzjQEZ+ona6ihS0jmfR85MbLed3RpDPEiM9M8exgnq1VMgpDq8GuaM ch5IzfKNeYvZDiWWr47ZzxFhYQTzOjTIdffOR1PgvIUDJnxOe/JXn5YUDvx/bX0b lMN1H82bKyhpY8IAc76zOxGnnC8zyzm1gd6+RM= X-Sasl-enc: ONzuAlJHvREeXYiD61Ja/6F895PD1G2o+KZ7tBegfQpv 1428658135 Received: from thinkpad-t440p (unknown [2.163.240.161]) by mail.messagingengine.com (Postfix) with ESMTPA id 3D09C680123; Fri, 10 Apr 2015 05:28:55 -0400 (EDT) From: Tassilo Horn References: <8761954apb.fsf@gnu.org> <831tjtfijq.fsf@gnu.org> <83zj6he14h.fsf@gnu.org> <87wq1kmnmh.fsf@gnu.org> <83d23cv2hj.fsf@gnu.org> Date: Fri, 10 Apr 2015 11:28:52 +0200 In-Reply-To: <83d23cv2hj.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 10 Apr 2015 10:58:32 +0300") Message-ID: <87sic8miwb.fsf@gnu.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Eli Zaretskii 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 From unknown Sun Jun 22 08:03:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 10 Apr 2015 12:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20285 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Tassilo Horn Cc: 20285@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 20285-submit@debbugs.gnu.org id=B20285.142866973222442 (code B ref 20285); Fri, 10 Apr 2015 12:43:02 +0000 Received: (at 20285) by debbugs.gnu.org; 10 Apr 2015 12:42:12 +0000 Received: from localhost ([127.0.0.1]:51924 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgYGB-0005pu-Ot for submit@debbugs.gnu.org; Fri, 10 Apr 2015 08:42:12 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:44575) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgYG8-0005pd-4w for 20285@debbugs.gnu.org; Fri, 10 Apr 2015 08:42:09 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NML00500CA4GG00@a-mtaout21.012.net.il> for 20285@debbugs.gnu.org; Fri, 10 Apr 2015 15:42:01 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NML0059CCM1FI20@a-mtaout21.012.net.il>; Fri, 10 Apr 2015 15:42:01 +0300 (IDT) Date: Fri, 10 Apr 2015 15:42:01 +0300 From: Eli Zaretskii In-reply-to: <87sic8miwb.fsf@gnu.org> X-012-Sender: halo1@inter.net.il Message-id: <83h9sotasm.fsf@gnu.org> References: <8761954apb.fsf@gnu.org> <831tjtfijq.fsf@gnu.org> <83zj6he14h.fsf@gnu.org> <87wq1kmnmh.fsf@gnu.org> <83d23cv2hj.fsf@gnu.org> <87sic8miwb.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Tassilo Horn > 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? From unknown Sun Jun 22 08:03:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking Resent-From: Tassilo Horn Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 10 Apr 2015 13:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20285 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 20285@debbugs.gnu.org Received: via spool by 20285-submit@debbugs.gnu.org id=B20285.142867163525519 (code B ref 20285); Fri, 10 Apr 2015 13:14:02 +0000 Received: (at 20285) by debbugs.gnu.org; 10 Apr 2015 13:13:55 +0000 Received: from localhost ([127.0.0.1]:51944 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgYks-0006dX-SA for submit@debbugs.gnu.org; Fri, 10 Apr 2015 09:13:55 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:38251) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgYkr-0006dP-Jn for 20285@debbugs.gnu.org; Fri, 10 Apr 2015 09:13:54 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id D9CC820C8B for <20285@debbugs.gnu.org>; Fri, 10 Apr 2015 09:13:48 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Fri, 10 Apr 2015 09:13:52 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=e7r/tBJ1Xr+xjrdnMBj3cFziHAM=; b=PMujT Mk28NAn38dEhq7QZzAa14uRAULmi/ebLtyfd+6aS1G6luKjaVoIrOqgh9fXNFSGn HbY61I0b+IwDDMivz8Sr1/q+zbCa35Bn3ZnZTTIPEFqw7Ky+XsPpU1QthXEqce+a S7lEwhFDThoDvLa0S0FQNaSQKxBdDS0flo16u4= X-Sasl-enc: X/qG5+NCM8i4NqZo68DOchSD9bYbdwDAQERejYdDPtrx 1428671632 Received: from thinkpad-t440p (unknown [2.163.240.161]) by mail.messagingengine.com (Postfix) with ESMTPA id 0505EC00015; Fri, 10 Apr 2015 09:13:51 -0400 (EDT) From: Tassilo Horn References: <8761954apb.fsf@gnu.org> <831tjtfijq.fsf@gnu.org> <83zj6he14h.fsf@gnu.org> <87wq1kmnmh.fsf@gnu.org> <83d23cv2hj.fsf@gnu.org> <87sic8miwb.fsf@gnu.org> <83h9sotasm.fsf@gnu.org> Date: Fri, 10 Apr 2015 15:13:49 +0200 In-Reply-To: <83h9sotasm.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 10 Apr 2015 15:42:01 +0300") Message-ID: <877ftkm8he.fsf@gnu.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Eli Zaretskii 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 From unknown Sun Jun 22 08:03:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 10 Apr 2015 13:29:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20285 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Tassilo Horn Cc: 20285@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 20285-submit@debbugs.gnu.org id=B20285.142867249426907 (code B ref 20285); Fri, 10 Apr 2015 13:29:02 +0000 Received: (at 20285) by debbugs.gnu.org; 10 Apr 2015 13:28:14 +0000 Received: from localhost ([127.0.0.1]:51949 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgYyj-0006zt-GJ for submit@debbugs.gnu.org; Fri, 10 Apr 2015 09:28:14 -0400 Received: from mtaout24.012.net.il ([80.179.55.180]:59722) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgYyf-0006za-HK for 20285@debbugs.gnu.org; Fri, 10 Apr 2015 09:28:10 -0400 Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NML00J00E8L9G00@mtaout24.012.net.il> for 20285@debbugs.gnu.org; Fri, 10 Apr 2015 16:19:30 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NML0089QECI8OA0@mtaout24.012.net.il>; Fri, 10 Apr 2015 16:19:30 +0300 (IDT) Date: Fri, 10 Apr 2015 16:28:03 +0300 From: Eli Zaretskii In-reply-to: <877ftkm8he.fsf@gnu.org> X-012-Sender: halo1@inter.net.il Message-id: <83bniwt8nw.fsf@gnu.org> References: <8761954apb.fsf@gnu.org> <831tjtfijq.fsf@gnu.org> <83zj6he14h.fsf@gnu.org> <87wq1kmnmh.fsf@gnu.org> <83d23cv2hj.fsf@gnu.org> <87sic8miwb.fsf@gnu.org> <83h9sotasm.fsf@gnu.org> <877ftkm8he.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Tassilo Horn > 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. From unknown Sun Jun 22 08:03:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 10 Apr 2015 13:33:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20285 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Tassilo Horn Cc: 20285@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 20285-submit@debbugs.gnu.org id=B20285.142867277627473 (code B ref 20285); Fri, 10 Apr 2015 13:33:03 +0000 Received: (at 20285) by debbugs.gnu.org; 10 Apr 2015 13:32:56 +0000 Received: from localhost ([127.0.0.1]:51953 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgZ3G-00078y-Ae for submit@debbugs.gnu.org; Fri, 10 Apr 2015 09:32:55 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:46090) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgZ3A-00078e-JG for 20285@debbugs.gnu.org; Fri, 10 Apr 2015 09:32:49 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NML00J00EHWZ600@a-mtaout22.012.net.il> for 20285@debbugs.gnu.org; Fri, 10 Apr 2015 16:32:42 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NML00J74EYHA290@a-mtaout22.012.net.il>; Fri, 10 Apr 2015 16:32:42 +0300 (IDT) Date: Fri, 10 Apr 2015 16:32:42 +0300 From: Eli Zaretskii In-reply-to: <877ftkm8he.fsf@gnu.org> X-012-Sender: halo1@inter.net.il Message-id: <83a8ygt8g5.fsf@gnu.org> References: <8761954apb.fsf@gnu.org> <831tjtfijq.fsf@gnu.org> <83zj6he14h.fsf@gnu.org> <87wq1kmnmh.fsf@gnu.org> <83d23cv2hj.fsf@gnu.org> <87sic8miwb.fsf@gnu.org> <83h9sotasm.fsf@gnu.org> <877ftkm8he.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Tassilo Horn > 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. From unknown Sun Jun 22 08:03:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking Resent-From: Tassilo Horn Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 10 Apr 2015 14:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20285 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 20285@debbugs.gnu.org Received: via spool by 20285-submit@debbugs.gnu.org id=B20285.142867523331886 (code B ref 20285); Fri, 10 Apr 2015 14:14:02 +0000 Received: (at 20285) by debbugs.gnu.org; 10 Apr 2015 14:13:53 +0000 Received: from localhost ([127.0.0.1]:52503 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgZgv-0008IE-2K for submit@debbugs.gnu.org; Fri, 10 Apr 2015 10:13:53 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:57293) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgZgs-0008I4-8m for 20285@debbugs.gnu.org; Fri, 10 Apr 2015 10:13:51 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 527F020C83 for <20285@debbugs.gnu.org>; Fri, 10 Apr 2015 10:13:44 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Fri, 10 Apr 2015 10:13:48 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=WducKOek/Q41iLB1FXqvJUENd0c=; b=I3YW2 7PHHWJ37KhnLjUKCqiIMCfWlLrmc93zbR/0MQv5RHeFsdl36PR3y02lyO1AaNNFf kMSu+QXi8DGc0zCWepw61Fd4Lq04UlNesNWjqoYV304qpUOyBFnVNsVL2nfDBBgm AF09h3tODg+F9Rm9XU688YmmQggsh4KUwn6krI= X-Sasl-enc: 1rYzDIIXPrVCkeOuUViwTE0nwX8cQNgbWdV7Q/AaGEvr 1428675227 Received: from thinkpad-t440p (unknown [2.163.240.161]) by mail.messagingengine.com (Postfix) with ESMTPA id 1ABD2C00020; Fri, 10 Apr 2015 10:13:46 -0400 (EDT) From: Tassilo Horn References: <8761954apb.fsf@gnu.org> <831tjtfijq.fsf@gnu.org> <83zj6he14h.fsf@gnu.org> <87wq1kmnmh.fsf@gnu.org> <83d23cv2hj.fsf@gnu.org> <87sic8miwb.fsf@gnu.org> <83h9sotasm.fsf@gnu.org> <877ftkm8he.fsf@gnu.org> <83a8ygt8g5.fsf@gnu.org> Date: Fri, 10 Apr 2015 16:13:44 +0200 In-Reply-To: <83a8ygt8g5.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 10 Apr 2015 16:32:42 +0300") Message-ID: <87y4m0kr53.fsf@gnu.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Eli Zaretskii 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 From unknown Sun Jun 22 08:03:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 10 Apr 2015 17:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20285 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Tassilo Horn Cc: 20285@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 20285-submit@debbugs.gnu.org id=B20285.142868716324871 (code B ref 20285); Fri, 10 Apr 2015 17:33:02 +0000 Received: (at 20285) by debbugs.gnu.org; 10 Apr 2015 17:32:43 +0000 Received: from localhost ([127.0.0.1]:52617 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgcnK-0006T4-HA for submit@debbugs.gnu.org; Fri, 10 Apr 2015 13:32:42 -0400 Received: from mtaout26.012.net.il ([80.179.55.182]:54086) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgcnH-0006Sp-Ta for 20285@debbugs.gnu.org; Fri, 10 Apr 2015 13:32:41 -0400 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NML00G00PSVMC00@mtaout26.012.net.il> for 20285@debbugs.gnu.org; Fri, 10 Apr 2015 20:33:52 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NML007A2Q4GI790@mtaout26.012.net.il>; Fri, 10 Apr 2015 20:33:52 +0300 (IDT) Date: Fri, 10 Apr 2015 20:32:33 +0300 From: Eli Zaretskii In-reply-to: <87y4m0kr53.fsf@gnu.org> X-012-Sender: halo1@inter.net.il Message-id: <836193ubwu.fsf@gnu.org> References: <8761954apb.fsf@gnu.org> <831tjtfijq.fsf@gnu.org> <83zj6he14h.fsf@gnu.org> <87wq1kmnmh.fsf@gnu.org> <83d23cv2hj.fsf@gnu.org> <87sic8miwb.fsf@gnu.org> <83h9sotasm.fsf@gnu.org> <877ftkm8he.fsf@gnu.org> <83a8ygt8g5.fsf@gnu.org> <87y4m0kr53.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Tassilo Horn > 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. From unknown Sun Jun 22 08:03:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 10 Apr 2015 18:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20285 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Tassilo Horn Cc: Eli Zaretskii , 20285@debbugs.gnu.org Received: via spool by 20285-submit@debbugs.gnu.org id=B20285.142869029129992 (code B ref 20285); Fri, 10 Apr 2015 18:25:02 +0000 Received: (at 20285) by debbugs.gnu.org; 10 Apr 2015 18:24:51 +0000 Received: from localhost ([127.0.0.1]:52657 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ygdbn-0007nd-1W for submit@debbugs.gnu.org; Fri, 10 Apr 2015 14:24:51 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:36911) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ygdbk-0007nT-V5 for 20285@debbugs.gnu.org; Fri, 10 Apr 2015 14:24:50 -0400 Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t3AIOjkB014179; Fri, 10 Apr 2015 14:24:45 -0400 Received: by pastel.home (Postfix, from userid 20848) id 454C223FB; Fri, 10 Apr 2015 14:24:45 -0400 (EDT) From: Stefan Monnier Message-ID: References: <8761954apb.fsf@gnu.org> <831tjtfijq.fsf@gnu.org> <83zj6he14h.fsf@gnu.org> <87wq1kmnmh.fsf@gnu.org> <83d23cv2hj.fsf@gnu.org> <87sic8miwb.fsf@gnu.org> <83h9sotasm.fsf@gnu.org> <877ftkm8he.fsf@gnu.org> <83a8ygt8g5.fsf@gnu.org> <87y4m0kr53.fsf@gnu.org> Date: Fri, 10 Apr 2015 14:24:45 -0400 In-Reply-To: <87y4m0kr53.fsf@gnu.org> (Tassilo Horn's message of "Fri, 10 Apr 2015 16:13:44 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0.2 X-NAI-Spam-Rules: 2 Rules triggered GEN_SPAM_FEATRE=0.2, RV5272=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5272> : inlines <2680> : streams <1420255> : uri <1903553> X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) 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 From unknown Sun Jun 22 08:03:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 10 Apr 2015 18:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20285 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 20285@debbugs.gnu.org, tsdh@gnu.org Reply-To: Eli Zaretskii Received: via spool by 20285-submit@debbugs.gnu.org id=B20285.142869133131755 (code B ref 20285); Fri, 10 Apr 2015 18:43:01 +0000 Received: (at 20285) by debbugs.gnu.org; 10 Apr 2015 18:42:11 +0000 Received: from localhost ([127.0.0.1]:52662 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgdsY-0008G7-Oj for submit@debbugs.gnu.org; Fri, 10 Apr 2015 14:42:10 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:59586) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgdsW-0008Fc-1B for 20285@debbugs.gnu.org; Fri, 10 Apr 2015 14:42:09 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NML00M00T7M2600@a-mtaout22.012.net.il> for 20285@debbugs.gnu.org; Fri, 10 Apr 2015 21:42:01 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NML00L5ZTA0UU60@a-mtaout22.012.net.il>; Fri, 10 Apr 2015 21:42:01 +0300 (IDT) Date: Fri, 10 Apr 2015 21:42:01 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83k2xjsu4m.fsf@gnu.org> References: <8761954apb.fsf@gnu.org> <831tjtfijq.fsf@gnu.org> <83zj6he14h.fsf@gnu.org> <87wq1kmnmh.fsf@gnu.org> <83d23cv2hj.fsf@gnu.org> <87sic8miwb.fsf@gnu.org> <83h9sotasm.fsf@gnu.org> <877ftkm8he.fsf@gnu.org> <83a8ygt8g5.fsf@gnu.org> <87y4m0kr53.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Stefan Monnier > Cc: Eli Zaretskii , 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. From unknown Sun Jun 22 08:03:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking Resent-From: Tassilo Horn Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 10 Apr 2015 20:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20285 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: Eli Zaretskii , 20285@debbugs.gnu.org Received: via spool by 20285-submit@debbugs.gnu.org id=B20285.14286973199422 (code B ref 20285); Fri, 10 Apr 2015 20:22:01 +0000 Received: (at 20285) by debbugs.gnu.org; 10 Apr 2015 20:21:59 +0000 Received: from localhost ([127.0.0.1]:52682 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgfR9-0002Rt-Bb for submit@debbugs.gnu.org; Fri, 10 Apr 2015 16:21:59 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:46620) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgfR6-0002Rk-I3 for 20285@debbugs.gnu.org; Fri, 10 Apr 2015 16:21:57 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id D99FD20D59 for <20285@debbugs.gnu.org>; Fri, 10 Apr 2015 16:21:51 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Fri, 10 Apr 2015 16:21:55 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=dtz3uUz5Z1RFLzpCMbM2eM19QOw=; b=YeGKN NkskJ38mZAXEDSntOduQ1MI5p4dpLUsIn/QGWsjp4ChaPbSMIWX/dKV0OYsK6XCm w5u+hc63f8oOMrNWFow6QIKwS+6rcCpDLEjuebszQ9X+g9d4GyZt3B5xeEqjM9Eh nN3E9zGnghSexEW0AHNd+4tL1/iDAGY0mncDfs= X-Sasl-enc: VLbGFpinRvmoySHWTcVO5Zj5372Z37yJMeEEgh1urCyj 1428697315 Received: from thinkpad-t440p (unknown [2.163.240.161]) by mail.messagingengine.com (Postfix) with ESMTPA id 9BE5BC00011; Fri, 10 Apr 2015 16:21:54 -0400 (EDT) From: Tassilo Horn References: <8761954apb.fsf@gnu.org> <831tjtfijq.fsf@gnu.org> <83zj6he14h.fsf@gnu.org> <87wq1kmnmh.fsf@gnu.org> <83d23cv2hj.fsf@gnu.org> <87sic8miwb.fsf@gnu.org> <83h9sotasm.fsf@gnu.org> <877ftkm8he.fsf@gnu.org> <83a8ygt8g5.fsf@gnu.org> <87y4m0kr53.fsf@gnu.org> Date: Fri, 10 Apr 2015 22:21:52 +0200 In-Reply-To: (Stefan Monnier's message of "Fri, 10 Apr 2015 14:24:45 -0400") Message-ID: <878udzentr.fsf@gnu.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Stefan Monnier 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 From unknown Sun Jun 22 08:03:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking Resent-From: Tassilo Horn Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 10 Apr 2015 20:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20285 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 20285@debbugs.gnu.org Received: via spool by 20285-submit@debbugs.gnu.org id=B20285.142869913912590 (code B ref 20285); Fri, 10 Apr 2015 20:53:02 +0000 Received: (at 20285) by debbugs.gnu.org; 10 Apr 2015 20:52:19 +0000 Received: from localhost ([127.0.0.1]:52722 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgfuU-0003Gz-7F for submit@debbugs.gnu.org; Fri, 10 Apr 2015 16:52:18 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:55650) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgfuS-0003Gq-19 for 20285@debbugs.gnu.org; Fri, 10 Apr 2015 16:52:16 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id A239A20C56 for <20285@debbugs.gnu.org>; Fri, 10 Apr 2015 16:52:11 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Fri, 10 Apr 2015 16:52:15 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=4p+xm0jWyOR3UGt/L4TVQait/fE=; b=Z6ayM RRcphMi8McyAVqL78HHjNRS/sokQw/M/KXInAt8PMi96JH4nninci6CUWkE3ygwA XkZUQ5Ky/ks993X8CLBOH2UA3CXiXMRjxuAkjbbQ5+kjR2yd0fCwUDwCtw+IWSKZ vpcy5webHDYFEVVdXaE4KVdAxMdTdVXUkJFwAE= X-Sasl-enc: CrlwBqJ1duuFQ2H1AQaNN7LRG6C/0tf++rOrHG8Re6LK 1428699135 Received: from thinkpad-t440p (unknown [2.163.240.161]) by mail.messagingengine.com (Postfix) with ESMTPA id CA949C00011; Fri, 10 Apr 2015 16:52:14 -0400 (EDT) From: Tassilo Horn References: <8761954apb.fsf@gnu.org> <831tjtfijq.fsf@gnu.org> <83zj6he14h.fsf@gnu.org> <87wq1kmnmh.fsf@gnu.org> <83d23cv2hj.fsf@gnu.org> <87sic8miwb.fsf@gnu.org> <83h9sotasm.fsf@gnu.org> <877ftkm8he.fsf@gnu.org> <83a8ygt8g5.fsf@gnu.org> <87y4m0kr53.fsf@gnu.org> <836193ubwu.fsf@gnu.org> Date: Fri, 10 Apr 2015 22:52:12 +0200 In-Reply-To: <836193ubwu.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 10 Apr 2015 20:32:33 +0300") Message-ID: <874monemf7.fsf@gnu.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Eli Zaretskii 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 From unknown Sun Jun 22 08:03:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 10 Apr 2015 21:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20285 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Tassilo Horn Cc: Eli Zaretskii , 20285@debbugs.gnu.org Received: via spool by 20285-submit@debbugs.gnu.org id=B20285.142870262118582 (code B ref 20285); Fri, 10 Apr 2015 21:51:02 +0000 Received: (at 20285) by debbugs.gnu.org; 10 Apr 2015 21:50:21 +0000 Received: from localhost ([127.0.0.1]:52753 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yggof-0004pe-2E for submit@debbugs.gnu.org; Fri, 10 Apr 2015 17:50:21 -0400 Received: from chene.dit.umontreal.ca ([132.204.246.20]:34349) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yggoc-0004pV-LY for 20285@debbugs.gnu.org; Fri, 10 Apr 2015 17:50:19 -0400 Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t3ALoGq2031636; Fri, 10 Apr 2015 17:50:16 -0400 Received: by pastel.home (Postfix, from userid 20848) id 441832BDF; Fri, 10 Apr 2015 17:50:16 -0400 (EDT) From: Stefan Monnier Message-ID: References: <8761954apb.fsf@gnu.org> <831tjtfijq.fsf@gnu.org> <83zj6he14h.fsf@gnu.org> <87wq1kmnmh.fsf@gnu.org> <83d23cv2hj.fsf@gnu.org> <87sic8miwb.fsf@gnu.org> <83h9sotasm.fsf@gnu.org> <877ftkm8he.fsf@gnu.org> <83a8ygt8g5.fsf@gnu.org> <87y4m0kr53.fsf@gnu.org> <878udzentr.fsf@gnu.org> Date: Fri, 10 Apr 2015 17:50:16 -0400 In-Reply-To: <878udzentr.fsf@gnu.org> (Tassilo Horn's message of "Fri, 10 Apr 2015 22:21:52 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5272=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5272> : inlines <2683> : streams <1420333> : uri <1903685> X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) > 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 From unknown Sun Jun 22 08:03:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking Resent-From: Tassilo Horn Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 11 Apr 2015 05:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20285 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: Eli Zaretskii , 20285@debbugs.gnu.org Received: via spool by 20285-submit@debbugs.gnu.org id=B20285.14287317006691 (code B ref 20285); Sat, 11 Apr 2015 05:55:02 +0000 Received: (at 20285) by debbugs.gnu.org; 11 Apr 2015 05:55:00 +0000 Received: from localhost ([127.0.0.1]:52792 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgoNf-0001jq-U6 for submit@debbugs.gnu.org; Sat, 11 Apr 2015 01:55:00 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:54250) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgoNc-0001jf-Bk for 20285@debbugs.gnu.org; Sat, 11 Apr 2015 01:54:57 -0400 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id A817A20556 for <20285@debbugs.gnu.org>; Sat, 11 Apr 2015 01:54:51 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Sat, 11 Apr 2015 01:54:55 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=+5eFOqS9VCVDeVZttMMbpPxBmIk=; b=TRo4v KPpbuey6i8W2v3OKDvvpKCt8kmtLEO4nq6mdysg3+IE5zalq7EFK+89B3c2tzKpV uiUiKgd7QsX3vjP4bXsBfSRxclsy1WwKo/i2r/ZQLmFH2b1lFYMdqrDVhZsNdvjX uSFdoEgy440+hNLwipdWUOpGBrm9/0H6HXIyWc= X-Sasl-enc: TcNYZeLFB9McJvjayJ44+yGbV4BdeiOzzGzXlKVl/bLT 1428731695 Received: from thinkpad-t440p (unknown [2.161.103.173]) by mail.messagingengine.com (Postfix) with ESMTPA id EE4D3C0001C; Sat, 11 Apr 2015 01:54:54 -0400 (EDT) From: Tassilo Horn References: <8761954apb.fsf@gnu.org> <831tjtfijq.fsf@gnu.org> <83zj6he14h.fsf@gnu.org> <87wq1kmnmh.fsf@gnu.org> <83d23cv2hj.fsf@gnu.org> <87sic8miwb.fsf@gnu.org> <83h9sotasm.fsf@gnu.org> <877ftkm8he.fsf@gnu.org> <83a8ygt8g5.fsf@gnu.org> <87y4m0kr53.fsf@gnu.org> <878udzentr.fsf@gnu.org> Date: Sat, 11 Apr 2015 07:54:52 +0200 In-Reply-To: (Stefan Monnier's message of "Fri, 10 Apr 2015 17:50:16 -0400") Message-ID: <87r3rrxl8z.fsf@gnu.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Stefan Monnier 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 From unknown Sun Jun 22 08:03:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 11 Apr 2015 06:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20285 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Tassilo Horn Cc: 20285@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 20285-submit@debbugs.gnu.org id=B20285.14287335539565 (code B ref 20285); Sat, 11 Apr 2015 06:26:02 +0000 Received: (at 20285) by debbugs.gnu.org; 11 Apr 2015 06:25:53 +0000 Received: from localhost ([127.0.0.1]:52799 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgorV-0002U9-69 for submit@debbugs.gnu.org; Sat, 11 Apr 2015 02:25:50 -0400 Received: from mtaout23.012.net.il ([80.179.55.175]:54962) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgorQ-0002Ts-H8 for 20285@debbugs.gnu.org; Sat, 11 Apr 2015 02:25:46 -0400 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0NMM00K00PDSP600@a-mtaout23.012.net.il> for 20285@debbugs.gnu.org; Sat, 11 Apr 2015 09:25:37 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NMM00KTXPUPM050@a-mtaout23.012.net.il>; Sat, 11 Apr 2015 09:25:37 +0300 (IDT) Date: Sat, 11 Apr 2015 09:25:39 +0300 From: Eli Zaretskii In-reply-to: <874monemf7.fsf@gnu.org> X-012-Sender: halo1@inter.net.il Message-id: <83h9snrxjw.fsf@gnu.org> References: <8761954apb.fsf@gnu.org> <831tjtfijq.fsf@gnu.org> <83zj6he14h.fsf@gnu.org> <87wq1kmnmh.fsf@gnu.org> <83d23cv2hj.fsf@gnu.org> <87sic8miwb.fsf@gnu.org> <83h9sotasm.fsf@gnu.org> <877ftkm8he.fsf@gnu.org> <83a8ygt8g5.fsf@gnu.org> <87y4m0kr53.fsf@gnu.org> <836193ubwu.fsf@gnu.org> <874monemf7.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Tassilo Horn > Cc: 20285@debbugs.gnu.org > Date: Fri, 10 Apr 2015 22:52:12 +0200 > > Eli Zaretskii 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. From unknown Sun Jun 22 08:03:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 11 Apr 2015 06:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20285 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 20285@debbugs.gnu.org, tsdh@gnu.org Reply-To: Eli Zaretskii Received: via spool by 20285-submit@debbugs.gnu.org id=B20285.142873384310084 (code B ref 20285); Sat, 11 Apr 2015 06:31:02 +0000 Received: (at 20285) by debbugs.gnu.org; 11 Apr 2015 06:30:43 +0000 Received: from localhost ([127.0.0.1]:52803 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgowE-0002cZ-Gh for submit@debbugs.gnu.org; Sat, 11 Apr 2015 02:30:43 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:39019) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ygow9-0002cF-24 for 20285@debbugs.gnu.org; Sat, 11 Apr 2015 02:30:39 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NMM00D00PVGX400@a-mtaout20.012.net.il> for 20285@debbugs.gnu.org; Sat, 11 Apr 2015 09:30:30 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NMM00D7OQ2TXL00@a-mtaout20.012.net.il>; Sat, 11 Apr 2015 09:30:29 +0300 (IDT) Date: Sat, 11 Apr 2015 09:30:32 +0300 From: Eli Zaretskii In-reply-to: X-012-Sender: halo1@inter.net.il Message-id: <83fv87rxbr.fsf@gnu.org> References: <8761954apb.fsf@gnu.org> <831tjtfijq.fsf@gnu.org> <83zj6he14h.fsf@gnu.org> <87wq1kmnmh.fsf@gnu.org> <83d23cv2hj.fsf@gnu.org> <87sic8miwb.fsf@gnu.org> <83h9sotasm.fsf@gnu.org> <877ftkm8he.fsf@gnu.org> <83a8ygt8g5.fsf@gnu.org> <87y4m0kr53.fsf@gnu.org> <878udzentr.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Stefan Monnier > Cc: Eli Zaretskii , 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. From unknown Sun Jun 22 08:03:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 11 Apr 2015 07:35:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20285 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Tassilo Horn Cc: 20285@debbugs.gnu.org, monnier@IRO.UMontreal.CA Reply-To: Eli Zaretskii Received: via spool by 20285-submit@debbugs.gnu.org id=B20285.142873767216269 (code B ref 20285); Sat, 11 Apr 2015 07:35:03 +0000 Received: (at 20285) by debbugs.gnu.org; 11 Apr 2015 07:34:32 +0000 Received: from localhost ([127.0.0.1]:52824 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ygpvz-0004EK-LT for submit@debbugs.gnu.org; Sat, 11 Apr 2015 03:34:32 -0400 Received: from mtaout24.012.net.il ([80.179.55.180]:39125) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ygpvv-0004E2-DG for 20285@debbugs.gnu.org; Sat, 11 Apr 2015 03:34:28 -0400 Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NMM00N00S7QPY00@mtaout24.012.net.il> for 20285@debbugs.gnu.org; Sat, 11 Apr 2015 10:25:47 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NMM00MS2SMY7B20@mtaout24.012.net.il>; Sat, 11 Apr 2015 10:25:47 +0300 (IDT) Date: Sat, 11 Apr 2015 10:34:23 +0300 From: Eli Zaretskii In-reply-to: <87r3rrxl8z.fsf@gnu.org> X-012-Sender: halo1@inter.net.il Message-id: <83bnivrudc.fsf@gnu.org> References: <8761954apb.fsf@gnu.org> <831tjtfijq.fsf@gnu.org> <83zj6he14h.fsf@gnu.org> <87wq1kmnmh.fsf@gnu.org> <83d23cv2hj.fsf@gnu.org> <87sic8miwb.fsf@gnu.org> <83h9sotasm.fsf@gnu.org> <877ftkm8he.fsf@gnu.org> <83a8ygt8g5.fsf@gnu.org> <87y4m0kr53.fsf@gnu.org> <878udzentr.fsf@gnu.org> <87r3rrxl8z.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Tassilo Horn > Cc: Eli Zaretskii , 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. From unknown Sun Jun 22 08:03:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 11 Apr 2015 11:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20285 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: tsdh@gnu.org Cc: 20285@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 20285-submit@debbugs.gnu.org id=B20285.142875205312802 (code B ref 20285); Sat, 11 Apr 2015 11:35:02 +0000 Received: (at 20285) by debbugs.gnu.org; 11 Apr 2015 11:34:13 +0000 Received: from localhost ([127.0.0.1]:52936 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ygtfw-0003KM-Ut for submit@debbugs.gnu.org; Sat, 11 Apr 2015 07:34:13 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:54381) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ygtft-0003Ja-SK for 20285@debbugs.gnu.org; Sat, 11 Apr 2015 07:34:11 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NMN00F00410M000@a-mtaout20.012.net.il> for 20285@debbugs.gnu.org; Sat, 11 Apr 2015 14:34:02 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NMN00FHV44Q5NB0@a-mtaout20.012.net.il>; Sat, 11 Apr 2015 14:34:02 +0300 (IDT) Date: Sat, 11 Apr 2015 14:34:05 +0300 From: Eli Zaretskii In-reply-to: <83bnivrudc.fsf@gnu.org> X-012-Sender: halo1@inter.net.il Message-id: <837ftigaqa.fsf@gnu.org> References: <8761954apb.fsf@gnu.org> <831tjtfijq.fsf@gnu.org> <83zj6he14h.fsf@gnu.org> <87wq1kmnmh.fsf@gnu.org> <83d23cv2hj.fsf@gnu.org> <87sic8miwb.fsf@gnu.org> <83h9sotasm.fsf@gnu.org> <877ftkm8he.fsf@gnu.org> <83a8ygt8g5.fsf@gnu.org> <87y4m0kr53.fsf@gnu.org> <878udzentr.fsf@gnu.org> <87r3rrxl8z.fsf@gnu.org> <83bnivrudc.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sat, 11 Apr 2015 10:34:23 +0300 > From: Eli Zaretskii > 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. From unknown Sun Jun 22 08:03:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking Resent-From: Tassilo Horn Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 11 Apr 2015 11:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20285 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 20285@debbugs.gnu.org, monnier@IRO.UMontreal.CA Received: via spool by 20285-submit@debbugs.gnu.org id=B20285.142875297015141 (code B ref 20285); Sat, 11 Apr 2015 11:50:02 +0000 Received: (at 20285) by debbugs.gnu.org; 11 Apr 2015 11:49:30 +0000 Received: from localhost ([127.0.0.1]:52945 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ygtuk-0003w9-1G for submit@debbugs.gnu.org; Sat, 11 Apr 2015 07:49:30 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:38642) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ygtui-0003vy-9i for 20285@debbugs.gnu.org; Sat, 11 Apr 2015 07:49:28 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id E7117203FF for <20285@debbugs.gnu.org>; Sat, 11 Apr 2015 07:49:23 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Sat, 11 Apr 2015 07:49:28 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=ngANHAvbjiF+iOYfj6R81971xj8=; b=Q58nZ 3CRDbchL4VxjbG6q5BLaJXy6HJ4OR260zVGJJ8eGjw0suCUJS6bW65b8ZE/Zl9PU 3bTFTetGR49O84H9KIiJj5FOVKQRhJuyMUnCiZVYRBcWmWtDXlFZ3LdyVadTsi9B 6a8/fHtwJEugEl6LDyHNPPBLK8ulqZtB/KFygE= X-Sasl-enc: q1ph9Mh+srYbdaBopN3GaojtJSEHfN7tYBZpcnooxD93 1428752967 Received: from thinkpad-t440p (unknown [2.161.103.173]) by mail.messagingengine.com (Postfix) with ESMTPA id E274A680110; Sat, 11 Apr 2015 07:49:26 -0400 (EDT) From: Tassilo Horn References: <8761954apb.fsf@gnu.org> <831tjtfijq.fsf@gnu.org> <83zj6he14h.fsf@gnu.org> <87wq1kmnmh.fsf@gnu.org> <83d23cv2hj.fsf@gnu.org> <87sic8miwb.fsf@gnu.org> <83h9sotasm.fsf@gnu.org> <877ftkm8he.fsf@gnu.org> <83a8ygt8g5.fsf@gnu.org> <87y4m0kr53.fsf@gnu.org> <878udzentr.fsf@gnu.org> <87r3rrxl8z.fsf@gnu.org> <83bnivrudc.fsf@gnu.org> Date: Sat, 11 Apr 2015 13:49:24 +0200 In-Reply-To: <83bnivrudc.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 11 Apr 2015 10:34:23 +0300") Message-ID: <87mw2ekhq3.fsf@gnu.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Eli Zaretskii 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 From unknown Sun Jun 22 08:03:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking Resent-From: Tassilo Horn Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 11 Apr 2015 12:40:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20285 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 20285@debbugs.gnu.org, monnier@IRO.UMontreal.CA Received: via spool by 20285-submit@debbugs.gnu.org id=B20285.142875599022923 (code B ref 20285); Sat, 11 Apr 2015 12:40:01 +0000 Received: (at 20285) by debbugs.gnu.org; 11 Apr 2015 12:39:50 +0000 Received: from localhost ([127.0.0.1]:52974 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YguhS-0005xd-5e for submit@debbugs.gnu.org; Sat, 11 Apr 2015 08:39:50 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:40857) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YguhR-0005xV-07 for 20285@debbugs.gnu.org; Sat, 11 Apr 2015 08:39:49 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 9AB1A206EB for <20285@debbugs.gnu.org>; Sat, 11 Apr 2015 08:39:44 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Sat, 11 Apr 2015 08:39:48 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=dIL9IDMvn6QtHYppepHY/0c+DP0=; b=ZVcOF dcYaSB8abSs6fSI5gDdK9bTsKKFTOtcEobVIW7hGmD9soPo9j2oX+qgKKMyTlE/s nvfNLS4ImRh32GDZ43zv2ytOGW+W31sKJxvJ2QBJouNUDj756dQXe50a3kHlW4M4 0YT1OwKqOh4i/DYArB4/jIOphPzmpWpISV3BhI= X-Sasl-enc: lAKwwrfiyxK/52rrH6rhIXrtG8qE8Zyr938c0cfQQsgL 1428755988 Received: from thinkpad-t440p (unknown [2.161.103.173]) by mail.messagingengine.com (Postfix) with ESMTPA id 97D42C0001D; Sat, 11 Apr 2015 08:39:47 -0400 (EDT) From: Tassilo Horn References: <8761954apb.fsf@gnu.org> <831tjtfijq.fsf@gnu.org> <83zj6he14h.fsf@gnu.org> <87wq1kmnmh.fsf@gnu.org> <83d23cv2hj.fsf@gnu.org> <87sic8miwb.fsf@gnu.org> <83h9sotasm.fsf@gnu.org> <877ftkm8he.fsf@gnu.org> <83a8ygt8g5.fsf@gnu.org> <87y4m0kr53.fsf@gnu.org> <878udzentr.fsf@gnu.org> <87r3rrxl8z.fsf@gnu.org> <83bnivrudc.fsf@gnu.org> <87mw2ekhq3.fsf@gnu.org> Date: Sat, 11 Apr 2015 14:39:45 +0200 In-Reply-To: <87mw2ekhq3.fsf@gnu.org> (Tassilo Horn's message of "Sat, 11 Apr 2015 13:49:24 +0200") Message-ID: <87r3rqq1ny.fsf@gnu.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Tassilo Horn 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 From unknown Sun Jun 22 08:03:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 11 Apr 2015 14:03:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20285 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Tassilo Horn Cc: Eli Zaretskii , 20285@debbugs.gnu.org Received: via spool by 20285-submit@debbugs.gnu.org id=B20285.1428760979958 (code B ref 20285); Sat, 11 Apr 2015 14:03:01 +0000 Received: (at 20285) by debbugs.gnu.org; 11 Apr 2015 14:02:59 +0000 Received: from localhost ([127.0.0.1]:53261 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ygvzu-0000FO-II for submit@debbugs.gnu.org; Sat, 11 Apr 2015 10:02:58 -0400 Received: from chene.dit.umontreal.ca ([132.204.246.20]:48803) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ygvzr-0000FF-RL for 20285@debbugs.gnu.org; Sat, 11 Apr 2015 10:02:57 -0400 Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t3BE2s1I009792; Sat, 11 Apr 2015 10:02:54 -0400 Received: by pastel.home (Postfix, from userid 20848) id D66012468; Sat, 11 Apr 2015 10:02:53 -0400 (EDT) From: Stefan Monnier Message-ID: References: <8761954apb.fsf@gnu.org> <831tjtfijq.fsf@gnu.org> <83zj6he14h.fsf@gnu.org> <87wq1kmnmh.fsf@gnu.org> <83d23cv2hj.fsf@gnu.org> <87sic8miwb.fsf@gnu.org> <83h9sotasm.fsf@gnu.org> <877ftkm8he.fsf@gnu.org> <83a8ygt8g5.fsf@gnu.org> <87y4m0kr53.fsf@gnu.org> <878udzentr.fsf@gnu.org> <87r3rrxl8z.fsf@gnu.org> <83bnivrudc.fsf@gnu.org> <87mw2ekhq3.fsf@gnu.org> Date: Sat, 11 Apr 2015 10:02:53 -0400 In-Reply-To: <87mw2ekhq3.fsf@gnu.org> (Tassilo Horn's message of "Sat, 11 Apr 2015 13:49:24 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5273=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5273> : inlines <2684> : streams <1420704> : uri <1904220> X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) > 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 From unknown Sun Jun 22 08:03:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking Resent-From: Tassilo Horn Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 11 Apr 2015 14:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20285 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: Eli Zaretskii , 20285@debbugs.gnu.org Received: via spool by 20285-submit@debbugs.gnu.org id=B20285.14287626303603 (code B ref 20285); Sat, 11 Apr 2015 14:31:02 +0000 Received: (at 20285) by debbugs.gnu.org; 11 Apr 2015 14:30:30 +0000 Received: from localhost ([127.0.0.1]:53274 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgwQL-0000uv-Qt for submit@debbugs.gnu.org; Sat, 11 Apr 2015 10:30:28 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:53685) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgwQF-0000uh-Gt for 20285@debbugs.gnu.org; Sat, 11 Apr 2015 10:30:14 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 93DB4207C2 for <20285@debbugs.gnu.org>; Sat, 11 Apr 2015 10:30:06 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Sat, 11 Apr 2015 10:30:10 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=S0gUNUdRi6DPLJ9A85+S3U3SLK0=; b=EINqn TQCuVWT+ifNdsidkc4hyNUJpjURnF51nbfzR3pZYm95gVCwo8f6DccK0C4o986Qj hMq0txaf0f+T/8d9DUSoMwOANbOn3iF/nOD46XcdNoAXLp6VRJriED1U/QkjYpvh w1yW8LPLbb5KRejEw+CWbNH+ZLHxorcwEGHDS0= X-Sasl-enc: BPbIyGjiQe95LpRQgWsGqblDzalAPDWAkTeN860Itqkq 1428762610 Received: from thinkpad-t440p (unknown [2.161.103.173]) by mail.messagingengine.com (Postfix) with ESMTPA id 917B4C00013; Sat, 11 Apr 2015 10:30:09 -0400 (EDT) From: Tassilo Horn References: <8761954apb.fsf@gnu.org> <831tjtfijq.fsf@gnu.org> <83zj6he14h.fsf@gnu.org> <87wq1kmnmh.fsf@gnu.org> <83d23cv2hj.fsf@gnu.org> <87sic8miwb.fsf@gnu.org> <83h9sotasm.fsf@gnu.org> <877ftkm8he.fsf@gnu.org> <83a8ygt8g5.fsf@gnu.org> <87y4m0kr53.fsf@gnu.org> <878udzentr.fsf@gnu.org> <87r3rrxl8z.fsf@gnu.org> <83bnivrudc.fsf@gnu.org> <87mw2ekhq3.fsf@gnu.org> Date: Sat, 11 Apr 2015 16:30:06 +0200 In-Reply-To: (Stefan Monnier's message of "Sat, 11 Apr 2015 10:02:53 -0400") Message-ID: <87egnqloup.fsf@gnu.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Stefan Monnier 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 From unknown Sun Jun 22 08:03:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 11 Apr 2015 14:46:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20285 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Tassilo Horn Cc: 20285@debbugs.gnu.org, monnier@IRO.UMontreal.CA Reply-To: Eli Zaretskii Received: via spool by 20285-submit@debbugs.gnu.org id=B20285.14287635285069 (code B ref 20285); Sat, 11 Apr 2015 14:46:01 +0000 Received: (at 20285) by debbugs.gnu.org; 11 Apr 2015 14:45:28 +0000 Received: from localhost ([127.0.0.1]:53286 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ygwf1-0001Jg-8W for submit@debbugs.gnu.org; Sat, 11 Apr 2015 10:45:27 -0400 Received: from mtaout24.012.net.il ([80.179.55.180]:33718) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ygwey-0001JP-DE for 20285@debbugs.gnu.org; Sat, 11 Apr 2015 10:45:25 -0400 Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NMN00A00CAJ4Z00@mtaout24.012.net.il> for 20285@debbugs.gnu.org; Sat, 11 Apr 2015 17:36:44 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NMN006FGCL71940@mtaout24.012.net.il>; Sat, 11 Apr 2015 17:36:44 +0300 (IDT) Date: Sat, 11 Apr 2015 17:45:21 +0300 From: Eli Zaretskii In-reply-to: <87r3rqq1ny.fsf@gnu.org> X-012-Sender: halo1@inter.net.il Message-id: <831tjqg1vi.fsf@gnu.org> References: <8761954apb.fsf@gnu.org> <831tjtfijq.fsf@gnu.org> <83zj6he14h.fsf@gnu.org> <87wq1kmnmh.fsf@gnu.org> <83d23cv2hj.fsf@gnu.org> <87sic8miwb.fsf@gnu.org> <83h9sotasm.fsf@gnu.org> <877ftkm8he.fsf@gnu.org> <83a8ygt8g5.fsf@gnu.org> <87y4m0kr53.fsf@gnu.org> <878udzentr.fsf@gnu.org> <87r3rrxl8z.fsf@gnu.org> <83bnivrudc.fsf@gnu.org> <87mw2ekhq3.fsf@gnu.org> <87r3rqq1ny.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Tassilo Horn > Cc: monnier@IRO.UMontreal.CA, 20285@debbugs.gnu.org > Date: Sat, 11 Apr 2015 14:39:45 +0200 > > Tassilo Horn 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. From unknown Sun Jun 22 08:03:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 11 Apr 2015 14:49:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20285 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Tassilo Horn Cc: 20285@debbugs.gnu.org, monnier@IRO.UMontreal.CA Reply-To: Eli Zaretskii Received: via spool by 20285-submit@debbugs.gnu.org id=B20285.14287636975376 (code B ref 20285); Sat, 11 Apr 2015 14:49:01 +0000 Received: (at 20285) by debbugs.gnu.org; 11 Apr 2015 14:48:17 +0000 Received: from localhost ([127.0.0.1]:53295 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ygwhl-0001Od-AK for submit@debbugs.gnu.org; Sat, 11 Apr 2015 10:48:17 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:46467) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ygwhi-0001ON-TZ for 20285@debbugs.gnu.org; Sat, 11 Apr 2015 10:48:15 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NMN00600CP7ZF00@a-mtaout22.012.net.il> for 20285@debbugs.gnu.org; Sat, 11 Apr 2015 17:48:08 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NMN006VOD48S270@a-mtaout22.012.net.il>; Sat, 11 Apr 2015 17:48:08 +0300 (IDT) Date: Sat, 11 Apr 2015 17:48:12 +0300 From: Eli Zaretskii In-reply-to: <87egnqloup.fsf@gnu.org> X-012-Sender: halo1@inter.net.il Message-id: <83zj6een6b.fsf@gnu.org> References: <8761954apb.fsf@gnu.org> <831tjtfijq.fsf@gnu.org> <83zj6he14h.fsf@gnu.org> <87wq1kmnmh.fsf@gnu.org> <83d23cv2hj.fsf@gnu.org> <87sic8miwb.fsf@gnu.org> <83h9sotasm.fsf@gnu.org> <877ftkm8he.fsf@gnu.org> <83a8ygt8g5.fsf@gnu.org> <87y4m0kr53.fsf@gnu.org> <878udzentr.fsf@gnu.org> <87r3rrxl8z.fsf@gnu.org> <83bnivrudc.fsf@gnu.org> <87mw2ekhq3.fsf@gnu.org> <87egnqloup.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Tassilo Horn > Cc: Eli Zaretskii , 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). From unknown Sun Jun 22 08:03:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 11 Apr 2015 15:16:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20285 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Tassilo Horn Cc: 20285@debbugs.gnu.org, monnier@IRO.UMontreal.CA Reply-To: Eli Zaretskii Received: via spool by 20285-submit@debbugs.gnu.org id=B20285.14287653037995 (code B ref 20285); Sat, 11 Apr 2015 15:16:01 +0000 Received: (at 20285) by debbugs.gnu.org; 11 Apr 2015 15:15:03 +0000 Received: from localhost ([127.0.0.1]:53332 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ygx7e-00024f-Bb for submit@debbugs.gnu.org; Sat, 11 Apr 2015 11:15:03 -0400 Received: from mtaout26.012.net.il ([80.179.55.182]:37434) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ygx7b-00024G-Hm for 20285@debbugs.gnu.org; Sat, 11 Apr 2015 11:15:00 -0400 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NMN00900E1E8600@mtaout26.012.net.il> for 20285@debbugs.gnu.org; Sat, 11 Apr 2015 18:16:13 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NMN0051YEF1BA50@mtaout26.012.net.il>; Sat, 11 Apr 2015 18:16:13 +0300 (IDT) Date: Sat, 11 Apr 2015 18:14:56 +0300 From: Eli Zaretskii In-reply-to: <87egnqloup.fsf@gnu.org> X-012-Sender: halo1@inter.net.il Message-id: <83wq1ielxr.fsf@gnu.org> References: <8761954apb.fsf@gnu.org> <831tjtfijq.fsf@gnu.org> <83zj6he14h.fsf@gnu.org> <87wq1kmnmh.fsf@gnu.org> <83d23cv2hj.fsf@gnu.org> <87sic8miwb.fsf@gnu.org> <83h9sotasm.fsf@gnu.org> <877ftkm8he.fsf@gnu.org> <83a8ygt8g5.fsf@gnu.org> <87y4m0kr53.fsf@gnu.org> <878udzentr.fsf@gnu.org> <87r3rrxl8z.fsf@gnu.org> <83bnivrudc.fsf@gnu.org> <87mw2ekhq3.fsf@gnu.org> <87egnqloup.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Tassilo Horn > Cc: Eli Zaretskii , 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. From unknown Sun Jun 22 08:03:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking Resent-From: Tassilo Horn Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 11 Apr 2015 19:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20285 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 20285@debbugs.gnu.org, monnier@IRO.UMontreal.CA Received: via spool by 20285-submit@debbugs.gnu.org id=B20285.142878026431503 (code B ref 20285); Sat, 11 Apr 2015 19:25:02 +0000 Received: (at 20285) by debbugs.gnu.org; 11 Apr 2015 19:24:24 +0000 Received: from localhost ([127.0.0.1]:53420 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yh10x-0008C2-No for submit@debbugs.gnu.org; Sat, 11 Apr 2015 15:24:24 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:48751) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yh10v-0008Bu-Bp for 20285@debbugs.gnu.org; Sat, 11 Apr 2015 15:24:22 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 124182094C for <20285@debbugs.gnu.org>; Sat, 11 Apr 2015 15:24:17 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Sat, 11 Apr 2015 15:24:21 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=2uiFS5y3/hlisFCXJAGzgre/LZs=; b=lIv14 KflUq0z3suBBL53j1esXlCduPUhLb2alb19q2FmpjJ/QRsKPB1yulCumsPQFCm4A PBI8qYOyl7Mpceh/2bSjtk7rfdEPVdKWqx3eIFyT0GbuIUn+wHMTsZW8NdaapMdI bDLY5IMZHZ5wmUoVcDfayOJx5I3VsjcDsu5PEw= X-Sasl-enc: cpKomzjen4qrBBO1JZouo5VK2pxiDXfkHoZtSmz5OxP/ 1428780260 Received: from thinkpad-t440p (unknown [2.161.103.173]) by mail.messagingengine.com (Postfix) with ESMTPA id 387BB6800D7; Sat, 11 Apr 2015 15:24:20 -0400 (EDT) From: Tassilo Horn References: <8761954apb.fsf@gnu.org> <831tjtfijq.fsf@gnu.org> <83zj6he14h.fsf@gnu.org> <87wq1kmnmh.fsf@gnu.org> <83d23cv2hj.fsf@gnu.org> <87sic8miwb.fsf@gnu.org> <83h9sotasm.fsf@gnu.org> <877ftkm8he.fsf@gnu.org> <83a8ygt8g5.fsf@gnu.org> <87y4m0kr53.fsf@gnu.org> <878udzentr.fsf@gnu.org> <87r3rrxl8z.fsf@gnu.org> <83bnivrudc.fsf@gnu.org> <87mw2ekhq3.fsf@gnu.org> <87r3rqq1ny.fsf@gnu.org> <831tjqg1vi.fsf@gnu.org> Date: Sat, 11 Apr 2015 21:24:18 +0200 In-Reply-To: <831tjqg1vi.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 11 Apr 2015 17:45:21 +0300") Message-ID: <87vbh2wjrx.fsf@gnu.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Eli Zaretskii 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 From unknown Sun Jun 22 08:03:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 11 Apr 2015 19:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20285 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Tassilo Horn Cc: 20285@debbugs.gnu.org, monnier@IRO.UMontreal.CA Reply-To: Eli Zaretskii Received: via spool by 20285-submit@debbugs.gnu.org id=B20285.14287815541178 (code B ref 20285); Sat, 11 Apr 2015 19:46:02 +0000 Received: (at 20285) by debbugs.gnu.org; 11 Apr 2015 19:45:54 +0000 Received: from localhost ([127.0.0.1]:53434 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yh1Ll-0000Iw-Hg for submit@debbugs.gnu.org; Sat, 11 Apr 2015 15:45:54 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:63439) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yh1Lh-0000Ie-Aq for 20285@debbugs.gnu.org; Sat, 11 Apr 2015 15:45:50 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NMN00800QTHX300@a-mtaout22.012.net.il> for 20285@debbugs.gnu.org; Sat, 11 Apr 2015 22:45:42 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NMN0080TQW6OAB0@a-mtaout22.012.net.il>; Sat, 11 Apr 2015 22:45:42 +0300 (IDT) Date: Sat, 11 Apr 2015 22:45:46 +0300 From: Eli Zaretskii In-reply-to: <87vbh2wjrx.fsf@gnu.org> X-012-Sender: halo1@inter.net.il Message-id: <83fv86e9ed.fsf@gnu.org> References: <8761954apb.fsf@gnu.org> <831tjtfijq.fsf@gnu.org> <83zj6he14h.fsf@gnu.org> <87wq1kmnmh.fsf@gnu.org> <83d23cv2hj.fsf@gnu.org> <87sic8miwb.fsf@gnu.org> <83h9sotasm.fsf@gnu.org> <877ftkm8he.fsf@gnu.org> <83a8ygt8g5.fsf@gnu.org> <87y4m0kr53.fsf@gnu.org> <878udzentr.fsf@gnu.org> <87r3rrxl8z.fsf@gnu.org> <83bnivrudc.fsf@gnu.org> <87mw2ekhq3.fsf@gnu.org> <87r3rqq1ny.fsf@gnu.org> <831tjqg1vi.fsf@gnu.org> <87vbh2wjrx.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Tassilo Horn > 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. From unknown Sun Jun 22 08:03:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking Resent-From: Tassilo Horn Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 11 Apr 2015 20:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20285 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 20285@debbugs.gnu.org, monnier@IRO.UMontreal.CA Received: via spool by 20285-submit@debbugs.gnu.org id=B20285.14287834284264 (code B ref 20285); Sat, 11 Apr 2015 20:18:02 +0000 Received: (at 20285) by debbugs.gnu.org; 11 Apr 2015 20:17:08 +0000 Received: from localhost ([127.0.0.1]:53495 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yh1pz-00016h-BM for submit@debbugs.gnu.org; Sat, 11 Apr 2015 16:17:07 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:37849) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yh1pw-00016Y-QJ for 20285@debbugs.gnu.org; Sat, 11 Apr 2015 16:17:05 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 8D441208C7 for <20285@debbugs.gnu.org>; Sat, 11 Apr 2015 16:17:00 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Sat, 11 Apr 2015 16:17:04 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=WUYJoQhOwOdeSBQt/erMYteCNPk=; b=GCZkv rSIBQ8C+ApiYkG760a2KFSNcvIa8NttRF+8Z5dZRHPcI60vOgiEbagZuHaFs/ysp V9lOPxPGDK87exdDBx2ZoNrx+Bi2vLGrlOYcpIhzrkvsZx3wnCr3kK5VNRgBjJuO Nt+7gwO4oF9Sb/3hOuWipFJkqBDzOUzx3O3TPs= X-Sasl-enc: p9SacdHWZAqWxzgAfdJug9Wu1QAe325kVvmhoQ6r16Sn 1428783424 Received: from thinkpad-t440p (unknown [2.161.103.173]) by mail.messagingengine.com (Postfix) with ESMTPA id A71E9680110; Sat, 11 Apr 2015 16:17:03 -0400 (EDT) From: Tassilo Horn References: <8761954apb.fsf@gnu.org> <831tjtfijq.fsf@gnu.org> <83zj6he14h.fsf@gnu.org> <87wq1kmnmh.fsf@gnu.org> <83d23cv2hj.fsf@gnu.org> <87sic8miwb.fsf@gnu.org> <83h9sotasm.fsf@gnu.org> <877ftkm8he.fsf@gnu.org> <83a8ygt8g5.fsf@gnu.org> <87y4m0kr53.fsf@gnu.org> <878udzentr.fsf@gnu.org> <87r3rrxl8z.fsf@gnu.org> <83bnivrudc.fsf@gnu.org> <87mw2ekhq3.fsf@gnu.org> <87r3rqq1ny.fsf@gnu.org> <831tjqg1vi.fsf@gnu.org> <87vbh2wjrx.fsf@gnu.org> <83fv86e9ed.fsf@gnu.org> Date: Sat, 11 Apr 2015 22:17:01 +0200 In-Reply-To: <83fv86e9ed.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 11 Apr 2015 22:45:46 +0300") Message-ID: <87egnqwhc2.fsf@gnu.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Eli Zaretskii 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 From unknown Sun Jun 22 08:03:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 12 Apr 2015 04:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20285 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Tassilo Horn Cc: Eli Zaretskii , 20285@debbugs.gnu.org Received: via spool by 20285-submit@debbugs.gnu.org id=B20285.142881153215323 (code B ref 20285); Sun, 12 Apr 2015 04:06:02 +0000 Received: (at 20285) by debbugs.gnu.org; 12 Apr 2015 04:05:32 +0000 Received: from localhost ([127.0.0.1]:53595 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yh99H-0003z5-F3 for submit@debbugs.gnu.org; Sun, 12 Apr 2015 00:05:31 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:46342) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yh99D-0003yu-Tf for 20285@debbugs.gnu.org; Sun, 12 Apr 2015 00:05:29 -0400 Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t3C45Pd6008384; Sun, 12 Apr 2015 00:05:25 -0400 Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 59F7EAE11C; Sun, 12 Apr 2015 00:05:25 -0400 (EDT) From: Stefan Monnier Message-ID: References: <8761954apb.fsf@gnu.org> <831tjtfijq.fsf@gnu.org> <83zj6he14h.fsf@gnu.org> <87wq1kmnmh.fsf@gnu.org> <83d23cv2hj.fsf@gnu.org> <87sic8miwb.fsf@gnu.org> <83h9sotasm.fsf@gnu.org> <877ftkm8he.fsf@gnu.org> <83a8ygt8g5.fsf@gnu.org> <87y4m0kr53.fsf@gnu.org> <878udzentr.fsf@gnu.org> <87r3rrxl8z.fsf@gnu.org> <83bnivrudc.fsf@gnu.org> <87mw2ekhq3.fsf@gnu.org> <87egnqloup.fsf@gnu.org> Date: Sun, 12 Apr 2015 00:05:25 -0400 In-Reply-To: <87egnqloup.fsf@gnu.org> (Tassilo Horn's message of "Sat, 11 Apr 2015 16:30:06 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0.2 X-NAI-Spam-Rules: 2 Rules triggered GEN_SPAM_FEATRE=0.2, RV5273=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5273> : inlines <2686> : streams <1421026> : uri <1904643> X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) > 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 From unknown Sun Jun 22 08:03:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 28 Apr 2022 10:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20285 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Tassilo Horn Cc: 20285@debbugs.gnu.org Received: via spool by 20285-submit@debbugs.gnu.org id=B20285.16511430478917 (code B ref 20285); Thu, 28 Apr 2022 10:51:01 +0000 Received: (at 20285) by debbugs.gnu.org; 28 Apr 2022 10:50:47 +0000 Received: from localhost ([127.0.0.1]:45534 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk1jT-0002Jk-At for submit@debbugs.gnu.org; Thu, 28 Apr 2022 06:50:47 -0400 Received: from quimby.gnus.org ([95.216.78.240]:53136) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk1jR-0002JW-MW for 20285@debbugs.gnu.org; Thu, 28 Apr 2022 06:50:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=W7TAmvivBbW/kwA8ctb7JGZ7hyz7MAQvsUUq+bSofgY=; b=ZqUIWMqo4QheD8N0wA9f2BsPMd v9n3suDHpWeV9lHUlRlAnAzDRSIX8XGQoaqyKHlQVQKu+xnnS+0dm1O7Ohpl1XciixuZ+wGhxIFtx wuOkNL1OuMIv1K/BUVRA6A8mNINgsfkVWsXvpbSt7/M/S6FlmwMLVU1/x+Jr8E7PiU5Q=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nk1jJ-0008IB-7r; Thu, 28 Apr 2022 12:50:39 +0200 From: Lars Ingebrigtsen References: <8761954apb.fsf@gnu.org> X-Now-Playing: Yukihiro Takahashi's _Blue Moon Blue_: "Where Are You Heading To?" Date: Thu, 28 Apr 2022 12:50:36 +0200 In-Reply-To: <8761954apb.fsf@gnu.org> (Tassilo Horn's message of "Thu, 09 Apr 2015 16:50:56 +0200") Message-ID: <87tuadmqgz.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Tassilo Horn 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 so [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Tassilo Horn 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 From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 28 06:50:58 2022 Received: (at control) by debbugs.gnu.org; 28 Apr 2022 10:50:58 +0000 Received: from localhost ([127.0.0.1]:45543 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk1je-0002KR-D1 for submit@debbugs.gnu.org; Thu, 28 Apr 2022 06:50:58 -0400 Received: from quimby.gnus.org ([95.216.78.240]:53150) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk1jc-0002Jw-OL for control@debbugs.gnu.org; Thu, 28 Apr 2022 06:50:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=tWaIoqhh+3A8fPmRj57CLRswp7yEHDcEa2sjrXc2H4w=; b=OSZ7JEi0xTYxpWvQ1y5dz0KX2J HlnPpbxPSikbXYJ9kqQUJ4jLSHxY0azDgtzR9sTxlADy5hdgWpymkX1IrzSl6rQ8eHUDzXp7dglvE uxsvPI+tjXadUu0YIvppYsHNP8z7FhkA6WoKc+8VZFWEdEQETliwuu5L8V+J+pQbhYHw=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nk1jV-0008IM-Ax for control@debbugs.gnu.org; Thu, 28 Apr 2022 12:50:51 +0200 Date: Thu, 28 Apr 2022 12:50:48 +0200 Message-Id: <87sfpxmqgn.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #20285 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: tags 20285 + moreinfo quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) tags 20285 + moreinfo quit From unknown Sun Jun 22 08:03:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking Resent-From: Tassilo Horn Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 28 Apr 2022 11:50:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20285 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Lars Ingebrigtsen Cc: 20285@debbugs.gnu.org Received: via spool by 20285-submit@debbugs.gnu.org id=B20285.165114657015955 (code B ref 20285); Thu, 28 Apr 2022 11:50:01 +0000 Received: (at 20285) by debbugs.gnu.org; 28 Apr 2022 11:49:30 +0000 Received: from localhost ([127.0.0.1]:45643 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk2eI-00049H-5t for submit@debbugs.gnu.org; Thu, 28 Apr 2022 07:49:30 -0400 Received: from eggs.gnu.org ([209.51.188.92]:54530) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk2eG-000493-4O for 20285@debbugs.gnu.org; Thu, 28 Apr 2022 07:49:28 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:49300) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nk2eA-0005dn-QN; Thu, 28 Apr 2022 07:49:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-reply-to:Date:Subject:To:From: References; bh=dvU+JuDw8kmSjGZdhw9CsGG6jeisy6Rn2+MB4Qz7Lqk=; b=qnzaSZVX9Ylu1R A5tfS0fwbbXdeumRWD3n5urb6nVcinu46Un5cWYxJAeq1cJV6jy/NF5JfWYDTUk0pBs1FIco9k9JJ zNu4bKt/l3DOFLjsNxG6k4aCxCTOPjuWtaflVRkI4uwFPESq/CS2vKrjDyKHcRfT1LP4KyjWR6Y6J LHzKmRm7rbG/a6ST0OnOHAXHpwaY5Nncm9SzvC1+2oGyb2zc/svnusl+wG2Lgjx8Kn8INM6YNt3mn xVkM6apQYLy2ayr9XqqhR5+c+FAfRiv8IUs3UGIdEJzgXBBvqCvgMQ5Ea5uW97rmznhpZgE/X2rve rV9v10RL27IbZWurimhA==; Received: from auth2-smtp.messagingengine.com ([66.111.4.228]:58565) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nk2e9-00043H-VA; Thu, 28 Apr 2022 07:49:22 -0400 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailauth.nyi.internal (Postfix) with ESMTP id D119527C0054; Thu, 28 Apr 2022 07:49:20 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Thu, 28 Apr 2022 07:49:20 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudejgdeggecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpehffgfhvfevufffjgfkgggtsehttdertddtredtnecuhfhrohhmpefvrghsshhi lhhoucfjohhrnhcuoehtshguhhesghhnuhdrohhrgheqnecuggftrfgrthhtvghrnhepud ejtdehuddvleffjeekteegvdehleehvdeufefhueekkeekhedvgfeggeffvefgnecuvehl uhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhrnhdomh gvshhmthhprghuthhhphgvrhhsohhnrghlihhthidqkeeijeefkeejkeegqdeifeehvdel kedqthhsughhpeepghhnuhdrohhrghesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 28 Apr 2022 07:49:20 -0400 (EDT) References: <8761954apb.fsf@gnu.org> <87tuadmqgz.fsf@gnus.org> User-agent: mu4e 1.7.13; emacs 29.0.50 From: Tassilo Horn Date: Thu, 28 Apr 2022 13:48:48 +0200 In-reply-to: <87tuadmqgz.fsf@gnus.org> Message-ID: <877d79h1hd.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Lars Ingebrigtsen 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 From unknown Sun Jun 22 08:03:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#20285: 25.0.50; blink-cursor-mode sometimes stops blinking Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 28 Apr 2022 11:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20285 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo To: Tassilo Horn Cc: 20285@debbugs.gnu.org Received: via spool by 20285-submit@debbugs.gnu.org id=B20285.165114668916190 (code B ref 20285); Thu, 28 Apr 2022 11:52:02 +0000 Received: (at 20285) by debbugs.gnu.org; 28 Apr 2022 11:51:29 +0000 Received: from localhost ([127.0.0.1]:45654 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk2gC-0004D4-Su for submit@debbugs.gnu.org; Thu, 28 Apr 2022 07:51:29 -0400 Received: from quimby.gnus.org ([95.216.78.240]:53904) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk2gA-0004Ck-Th for 20285@debbugs.gnu.org; Thu, 28 Apr 2022 07:51:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=C1/YZddGbT1/O8ttOYf2GPO40hO1KkrM9+nwk7Lg8CI=; b=V4ZtKx07Gn5Bc0FeOYREdZfI/r oIzwlEMz73KAfdlELkarzLDSOYGc+mstTM2gKs7Vi0aT2bV+nHAAXSOZ7Vksq0UzXQaBQ3lM7gf5F a72YEjNefLQiH+M0WdTFyhYeCo+t9N+mTTTPwzLnN53ax5h4t2e1pbjItKfPxmQJG7Ok=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nk2g2-0000Mk-Ji; Thu, 28 Apr 2022 13:51:20 +0200 From: Lars Ingebrigtsen References: <8761954apb.fsf@gnu.org> <87tuadmqgz.fsf@gnus.org> <877d79h1hd.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAFVBMVEXj4tqPimhYVUMQ DQosKRq1s6L///8cqW0gAAAAAWJLR0QGYWa4fQAAAAd0SU1FB+YEHAszB4XcA6oAAAG+SURBVDjL nZRLkqMwDIYFhfbg6d4nxjkASLNPkA5gpob7X6XlBwl5zGZUlZStz79syTIAZoMbiUiVWEhYI416 NXfjg7mJVTJTRfqiCdApM1VTNpGcyROB7E4LQ1qHthLoaGqxpOgfQLJExaC8Ak5eXW7jAXA6lpn3 eo5JswMVO6whr3rrxwPgnIkuBvytAtuUKW2YBD6oD2J5JoUBqSBvbirSAnLOlpctJVkWrYqyiXLd KqRDMQQNFjgEP7iSWamygouAqfSA22b/G0YoxlDd61DMubPz3sFsUdw0yvyLwbXX5tSsfYvXDlQY 8eK/pr9D+xtjDxEagJMBmm2PiJPF+8ZTGxmjw9iBiLQIWzs12JzgArhg3+DWpTwaBMQJoTsB9JhC bS6Dbd2+/8zr1l2uPfaIcV19BnZDGizR4O2gg/OLDfeyq9UhLFaDsxts6O+A9mZZ7AqfmkFqA3Hw uZpHkOcG5F2Rft6PefYKqNa+AtZ7p6brqMAauYCskKUsgr3XyqGeFPuM76oCZH8DD+fxuJr98hHQ R1Df0edQ+gY4g/mQ5YviH+DZ/h88TJ6B0L287yB9e15CcXksj/sj/gF6g9mAQU+1XgAAACV0RVh0 ZGF0ZTpjcmVhdGUAMjAyMi0wNC0yOFQxMTo1MTowNiswMDowMNFXZ60AAAAldEVYdGRhdGU6bW9k aWZ5ADIwMjItMDQtMjhUMTE6NTE6MDYrMDA6MDCgCt8RAAAAAElFTkSuQmCC X-Now-Playing: Meat Beat Manifesto's _This Is Fascism (1)_: "This Is Fascism (Meat Beat Manifesto Mix)" Date: Thu, 28 Apr 2022 13:51:18 +0200 In-Reply-To: <877d79h1hd.fsf@gnu.org> (Tassilo Horn's message of "Thu, 28 Apr 2022 13:48:48 +0200") Message-ID: <87fslxl93d.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Tassilo Horn writes: > No, I don't think so. Feel free to close the report. Thanks for checking; I'm closing this bug report, then. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Tassilo Horn 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 From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 28 07:51:38 2022 Received: (at control) by debbugs.gnu.org; 28 Apr 2022 11:51:38 +0000 Received: from localhost ([127.0.0.1]:45657 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk2gM-0004DT-4r for submit@debbugs.gnu.org; Thu, 28 Apr 2022 07:51:38 -0400 Received: from quimby.gnus.org ([95.216.78.240]:53918) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk2gL-0004DD-0B for control@debbugs.gnu.org; Thu, 28 Apr 2022 07:51:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=ietCPXODMVIYvRLdJ95yOaJ9p7rXSO5r5ebjofgbpT4=; b=RJbDjnGSWd2Y4GDMkOdLfrzg9R nAM5NvlbNo/X5at24W1hRf4uIfNHncXntdqv3ks5k8YQM7i4Xo1exzPDx6NM4VPMPq8rk9rHeL7jc /aVlwbf8ed9f/jcqw1yc+36aZQinxfAPzqqGBkukXY6O444kswxIBoTDZqqiYyavFU+s=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nk2gD-0000Mu-Db for control@debbugs.gnu.org; Thu, 28 Apr 2022 13:51:31 +0200 Date: Thu, 28 Apr 2022 13:51:28 +0200 Message-Id: <87ee1hl933.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #20285 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: close 20285 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) close 20285 quit