From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 22 05:46:06 2015 Received: (at submit) by debbugs.gnu.org; 22 Apr 2015 09:46:06 +0000 Received: from localhost ([127.0.0.1]:35776 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YkrEK-0001Qi-33 for submit@debbugs.gnu.org; Wed, 22 Apr 2015 05:46:05 -0400 Received: from eggs.gnu.org ([208.118.235.92]:53138) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YkrEG-0001Q8-Et for submit@debbugs.gnu.org; Wed, 22 Apr 2015 05:46:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YkrE8-00021C-CM for submit@debbugs.gnu.org; Wed, 22 Apr 2015 05:45:55 -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]:57889) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkrE8-000218-9U for submit@debbugs.gnu.org; Wed, 22 Apr 2015 05:45:52 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38399) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkrE5-00023g-2y for bug-gnu-emacs@gnu.org; Wed, 22 Apr 2015 05:45:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YkrE0-0001zo-05 for bug-gnu-emacs@gnu.org; Wed, 22 Apr 2015 05:45:49 -0400 Received: from deliver.uni-koblenz.de ([141.26.64.15]:55319) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkrDz-0001zi-KD for bug-gnu-emacs@gnu.org; Wed, 22 Apr 2015 05:45:43 -0400 Received: from thinkpad-t440p (dhcp229.uni-koblenz.de [141.26.71.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by deliver.uni-koblenz.de (Postfix) with ESMTPSA id 059961A84F2 for ; Wed, 22 Apr 2015 11:45:43 +0200 (CEST) From: Tassilo Horn To: bug-gnu-emacs@gnu.org Subject: 25.0.50; Sometimes no fontification with jit-lock-defer-time User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) Date: Wed, 22 Apr 2015 11:45:42 +0200 Message-ID: <87a8y0iji1.fsf@gnu.org> 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-Debbugs-Envelope-To: submit 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 (-----) I use the settings (setq jit-lock-defer-time 0.0312 jit-lock-stealth-nice 0.117 jit-lock-stealth-time 0.23) to speed up scrolling in large buffers with complex font-lock rules. That basically works nice. However, quite often I'm faced with buffers that are not fontified before I do something, e.g., move point. This frequently happens when installing/upgrading packages with the package manager. That shows the buffer containing the byte-compliation messages with fontified warnings and errors. Every second time or so, I'm faced with a completely unfontified buffer that gets fontified only after selecting the window showing the buffer. Another and even reproducible case is `report-emacs-bug'. It goes like this: 1. emacs -Q 2. eval my above settings in *scratch* 3. M-x report-emacs-bug The new message buffer is completely unfontified initially. As soon as you move point, font-lock kicks in and the header lines get their proper fontification. Or maybe it's the other way round, i.e., the buffer is created, then redisplayed, then the fontification takes place but no redisplay is performed thereafter. Of course, what I had expected in both cases is that I get fontified buffers almost immediately, e.g., after 0.0312 seconds. (In the byte-compile case I could imagine that it takes a bit longer if there is so much output that redisplay isn't called for some longer period.) Fun anecdote: I really have a pretty fast machine but still scrolling, e.g., buffer.c, by pressing and holding `C-v' causes visible scrolling for 1-2 seconds, and then the display freezes. Emacs burns one core, and the next visible change I can observe is that the end of the buffer is displayed after the ~6 seconds where emacs seems frozen. That lead me to looking for solutions, and deferred JIT lock and stealth lock seemed like a good idea (and they are!). But I've been in contact with some other emacs user who didn't face these display freezes on several machines with lower specs than mine. Then we tried figuring out where's the difference. I've tested several different machines, emacs versions, toolkits, emacs -nw, optimized builds and (almost) always got the display freezes. He did the same and didn't encounter the freezes. What would you guess as likely culprit? Solution to the riddle: V'ir pbasvtherq zl K jvaqbj flfgrz jvgu n irel uvtu xrlobneq ercrng engr bs 58 Um. Guhf, jura V cerff naq ubyq `P-i', `fpebyy-hc-pbzznaq' vf pnyyrq 58 gvzrf cre frpbaq juvpu frrzf gb or fb tbqqnz snfg gung sbag-ybpx trgf fb ohfl gung erqvfcynl unf ab punapr gb xvpx va. Fb Ryv, va pnfr lbh ernq guvf, urer vf nabgure pnfr jurer fbzr sbeprq crevbqvp erqvfcynl pbhyq or avpr. In GNU Emacs 25.0.50.12 (x86_64-unknown-linux-gnu, GTK+ Version 3.16.2) of 2015-04-21 on thinkpad-t440p Windowing system distributor `The X.Org Foundation', version 11.0.11701000 System Description: Arch Linux Configured using: `configure --enable-checking=no --without-m17n-flt 'CFLAGS=-march=native -O2'' Configured features: XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS NOTIFY ACL GNUTLS LIBXML2 FREETYPE 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: rcirc-track-minor-mode: t auto-dictionary-mode: t flyspell-mode: t reftex-mode: t TeX-PDF-mode: t TeX-source-correlate-mode: t magit-auto-revert-mode: t diff-auto-refine-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 th/sentence-hl-mode: t global-subword-mode: t subword-mode: t savehist-mode: t show-paren-mode: t ivy-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: Wrote /home/horn/Repos/uni/ttc15-train-benchmark-funnyqt/doc/ttc-train-benchmark.tex Type `C-c C-l' to display results of compilation. LaTeX: successfully formatted {3} pages Quit Type `C-c C-l' to display results of compilation. LaTeX: successfully formatted {3} pages pdf-view-goto-page: No such page: 4 Auto-saving...done Saving file /home/horn/Repos/uni/ttc15-train-benchmark-funnyqt/doc/ttc-train-benchmark.tex... Wrote /home/horn/Repos/uni/ttc15-train-benchmark-funnyqt/doc/ttc-train-benchmark.tex 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 rcirc-color rcirc-controls rcirc-late-fix rcirc bug-reference reftex-sel debug reftex-ref reftex-parse reftex-cite pdf-sync pdf-annot pdf-outline pdf-links pdf-history texmathp 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 pkg-info lisp-mnt epl mm-archive magit-key-mode magit view git-rebase-mode git-commit-mode log-edit pcvs-util add-log autorevert filenotify hippie-exp color org-rmail org-mhe org-irc org-info org-gnus org-docview doc-view org-bibtex bibtex org-bbdb org-w3m swiper sort smiley gnus-cite gnus-async gnus-bcklg gnus-ml misearch multi-isearch winner filecache vc vc-dispatcher vc-git diff-mode cus-theme eieio-opt speedbar sb-image ezimage dframe nndraft nnmh rot13 utf-7 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 gnutls network-stream nsm starttls url-http url-gw url-auth hl-line 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 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 names edebug 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 ivy delsel icomplete mb-depth smart-mode-line-respectful-theme smart-mode-line-light-theme smart-mode-line rich-minority rx bs windmove elec-pair edmacro kmacro cl-loaddefs cl-lib gnus-load subr-x pcase tsdh-light-theme finder-inf info easymenu memory-usage-autoloads advice help-fns package epg-config mule-util 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 dbusbind gfilenotify dynamic-setting system-font-setting font-render-setting move-toolbar gtk x-toolkit x multi-tty make-network-process emacs) Memory information: ((conses 16 1602223 179931) (symbols 48 67807 0) (miscs 40 2020 3774) (strings 32 263270 26363) (string-bytes 1 9086606) (vectors 16 77447) (vector-slots 8 2097120 172273) (floats 8 1915 1406) (intervals 56 144016 5164) (buffers 976 90) (heap 1024 130819 25998)) From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 22 06:33:01 2015 Received: (at 20404) by debbugs.gnu.org; 22 Apr 2015 10:33:01 +0000 Received: from localhost ([127.0.0.1]:35790 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ykrxk-0002at-SP for submit@debbugs.gnu.org; Wed, 22 Apr 2015 06:33:01 -0400 Received: from mtaout27.012.net.il ([80.179.55.183]:33276) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ykrxi-0002ab-Et for 20404@debbugs.gnu.org; Wed, 22 Apr 2015 06:32:59 -0400 Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NN700900ED24100@mtaout27.012.net.il> for 20404@debbugs.gnu.org; Wed, 22 Apr 2015 13:27:40 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NN700620EE43V30@mtaout27.012.net.il>; Wed, 22 Apr 2015 13:27:40 +0300 (IDT) Date: Wed, 22 Apr 2015 13:32:36 +0300 From: Eli Zaretskii Subject: Re: bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time In-reply-to: <87a8y0iji1.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: Tassilo Horn Message-id: <837ft44fnf.fsf@gnu.org> References: <87a8y0iji1.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 20404 Cc: 20404@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii 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 (+) > Resent-Sender: help-debbugs@gnu.org > From: Tassilo Horn > Date: Wed, 22 Apr 2015 11:45:42 +0200 > > I use the settings > > (setq jit-lock-defer-time 0.0312 > jit-lock-stealth-nice 0.117 > jit-lock-stealth-time 0.23) > > to speed up scrolling in large buffers with complex font-lock rules. > That basically works nice. However, quite often I'm faced with buffers > that are not fontified before I do something, e.g., move point. > > This frequently happens when installing/upgrading packages with the > package manager. That shows the buffer containing the byte-compliation > messages with fontified warnings and errors. Every second time or so, > I'm faced with a completely unfontified buffer that gets fontified only > after selecting the window showing the buffer. > > Another and even reproducible case is `report-emacs-bug'. It goes like > this: > > 1. emacs -Q > 2. eval my above settings in *scratch* > 3. M-x report-emacs-bug > > The new message buffer is completely unfontified initially. As soon as > you move point, font-lock kicks in and the header lines get their proper > fontification. Or maybe it's the other way round, i.e., the buffer is > created, then redisplayed, then the fontification takes place but no > redisplay is performed thereafter. Sounds like the idle timer that is started by jit-lock-defer-time never runs after the buffer is displayed. Could it be that it already ran before the display? From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 22 12:31:15 2015 Received: (at 20404) by debbugs.gnu.org; 22 Apr 2015 16:31:15 +0000 Received: from localhost ([127.0.0.1]:36703 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YkxYQ-0004Br-Jy for submit@debbugs.gnu.org; Wed, 22 Apr 2015 12:31:14 -0400 Received: from colin.muc.de ([193.149.48.1]:40146 helo=mail.muc.de) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YkxYO-0004Bi-8R for 20404@debbugs.gnu.org; Wed, 22 Apr 2015 12:31:13 -0400 Received: (qmail 68602 invoked by uid 3782); 22 Apr 2015 16:31:10 -0000 Date: 22 Apr 2015 16:31:10 -0000 Message-ID: <20150422163110.68601.qmail@mail.muc.de> From: Alan Mackenzie To: 20404@debbugs.gnu.org Subject: Re: bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time Organization: muc.de e.V. In-Reply-To: X-Newsgroups: gnu.emacs.bug User-Agent: tin/2.2.0-20131224 ("Lochindaal") (UNIX) (FreeBSD/10.1-RELEASE (amd64)) X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20404 Cc: Tassilo Horn 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.7 (/) In article you wrote: [ .... ] > Fun anecdote: I really have a pretty fast machine but still scrolling, > e.g., buffer.c, by pressing and holding `C-v' causes visible scrolling > for 1-2 seconds, and then the display freezes. Emacs burns one core, > and the next visible change I can observe is that the end of the buffer > is displayed after the ~6 seconds where emacs seems frozen. That lead > me to looking for solutions, and deferred JIT lock and stealth lock > seemed like a good idea (and they are!). There's a solution (or, depending on your point of view, a workaround) for this. You're using Emacs-25, so set fast-but-imprecise-scrolling to t, or customize it (it's in customisation group "scrolling"). What it does is only to fontify screen-worths it's about to display, rather than fontifying the entire buffer portion that is scrolled over. The disadvantage is that if you're using faces with different heights, the exact place the scrolling ends up at might not be quite correct, but if you're holding down C-v anyway, this might not matter too much. [ .... ] > In GNU Emacs 25.0.50.12 (x86_64-unknown-linux-gnu, GTK+ Version 3.16.2) > of 2015-04-21 on thinkpad-t440p -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 22 13:37:18 2015 Received: (at 20404) by debbugs.gnu.org; 22 Apr 2015 17:37:18 +0000 Received: from localhost ([127.0.0.1]:36742 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YkyaM-0007B0-4T for submit@debbugs.gnu.org; Wed, 22 Apr 2015 13:37:18 -0400 Received: from chene.dit.umontreal.ca ([132.204.246.20]:54291) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YkyaJ-0007Ar-2s for 20404@debbugs.gnu.org; Wed, 22 Apr 2015 13:37:16 -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 t3MHbDqr014191; Wed, 22 Apr 2015 13:37:14 -0400 Received: by pastel.home (Postfix, from userid 20848) id 9CF2633E7; Wed, 22 Apr 2015 13:37:13 -0400 (EDT) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time Message-ID: References: <87a8y0iji1.fsf@gnu.org> <20150422163110.68601.qmail@mail.muc.de> Date: Wed, 22 Apr 2015 13:37:13 -0400 In-Reply-To: <20150422163110.68601.qmail@mail.muc.de> (Alan Mackenzie's message of "22 Apr 2015 16:31:10 -0000") 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 RV5284=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5284> : inlines <2779> : streams <1426815> : uri <1913178> X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 20404 Cc: 20404@debbugs.gnu.org, Tassilo Horn 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 (-) [ OFFTOPIC: the bug report is not about performance but about a functional bug in jit-lock-defer. ] > There's a solution (or, depending on your point of view, a workaround) > for this. You're using Emacs-25, so set fast-but-imprecise-scrolling to > t, or customize it (it's in customisation group "scrolling"). FWIW, on my machine, this doesn't make much difference: a single "font-lock one screen's worth" takes much too long, so after that one screen is displayed, Emacs takes a while catching up (with no display at all in the mean time). That's why after you installed your change, I installed the one I had suggested (which tweaks the decision about when to skip redisplay and when to defer font-lock and relies on using jit-lock-defer-time). In my tests, it worked significantly better (was able to keep up). So I recommend you try jit-lock-defer-time set to 0 instead of using fast-but-imprecise-scrolling, and see if you like the resulting behavior. IIUC if Emacs can *almost* keep up, then fast-but-imprecise-scrolling might be just enough to let it keep up, in which case the behavior may look be better than with jit-lock-defer-time (because the text is never displayed unfontified). But if the repeat rate is faster than that, then jit-lock-defer-time should give noticeably better results. Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 22 15:32:06 2015 Received: (at 20404) by debbugs.gnu.org; 22 Apr 2015 19:32:06 +0000 Received: from localhost ([127.0.0.1]:36797 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yl0NS-0001QH-2M for submit@debbugs.gnu.org; Wed, 22 Apr 2015 15:32:06 -0400 Received: from colin.muc.de ([193.149.48.1]:43201 helo=mail.muc.de) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yl0NO-0001Pa-PG for 20404@debbugs.gnu.org; Wed, 22 Apr 2015 15:32:04 -0400 Received: (qmail 16181 invoked by uid 3782); 22 Apr 2015 19:32:00 -0000 Received: from acm.muc.de (p548A4565.dip0.t-ipconnect.de [84.138.69.101]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 22 Apr 2015 21:32:00 +0200 Received: (qmail 6664 invoked by uid 1000); 22 Apr 2015 19:32:04 -0000 Date: Wed, 22 Apr 2015 19:32:04 +0000 To: Stefan Monnier Subject: Re: bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time Message-ID: <20150422193204.GC4120@acm.fritz.box> References: <87a8y0iji1.fsf@gnu.org> <20150422163110.68601.qmail@mail.muc.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20404 Cc: 20404@debbugs.gnu.org, Tassilo Horn 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.7 (/) Hello, Stefan. On Wed, Apr 22, 2015 at 01:37:13PM -0400, Stefan Monnier wrote: > [ OFFTOPIC: the bug report is not about performance but about > a functional bug in jit-lock-defer. ] > > There's a solution (or, depending on your point of view, a workaround) > > for this. You're using Emacs-25, so set fast-but-imprecise-scrolling to > > t, or customize it (it's in customisation group "scrolling"). > FWIW, on my machine, this doesn't make much difference: a single > "font-lock one screen's worth" takes much too long, so after that one > screen is displayed, Emacs takes a while catching up (with no display at > all in the mean time). How long is "too long"? Do you mean that, with fast-but-imprecise-scrolling non-nil, jit-lock-defer-time nil, holding down C-v, that there is no redisplay for several seconds? That would be suggesting that the time to scroll one screen (without fontification) is longer than your auto-repeat interval, which sounds implausible. > That's why after you installed your change, I installed the one I had > suggested (which tweaks the decision about when to skip redisplay and > when to defer font-lock and relies on using jit-lock-defer-time). > In my tests, it worked significantly better (was able to keep up). > So I recommend you try jit-lock-defer-time set to 0 instead of using > fast-but-imprecise-scrolling, and see if you like the > resulting behavior. No, I don't. ;-) What I see is somewhat jerky scrolling, mainly unfontified, but with some fontification flashing on each screen some short time (?10-100 milliseconds) before the next scroll. What I see with fast-but-imprecise-scrolling is somewhat jerky scrolling, but each displayed screen being fully fontified. The delay between drawing the screens is never more than about half a second, mostly less than that, and the delay between releasing C-v and the screen stabilising is likewise no more than half a second. Also, when I attempt to disable jit-lock-defer-time (through the customisation interface) the jit-lock-defer-timer keeps running, and the "defer" mechanism keeps running with it. This seems worth a bug report in its own right. > IIUC if Emacs can *almost* keep up, then fast-but-imprecise-scrolling > might be just enough to let it keep up, in which case the behavior may > look be better than with jit-lock-defer-time (because the text is never > displayed unfontified). But if the repeat rate is faster than that, then > jit-lock-defer-time should give noticeably better results. I don't understand how what you're seeing is so bad. I thought you had a powerful workstation, a class above a typical PC, and that you had your auto-repeat rate at a conservative figure (25 or 30 per second) rather than the insane rate (~40 per second) I have. I have a 5 year old machine, not a blazingly fast super-modern one, and my window is 64 lines deep. fast-but-imprecise-scrolling doesn't require Emacs almost to keep up. It merely prevents a redisplay being directly triggered by the auto-repeated scrolling, instead allowing a redisplay only when there is no input waiting. On my machine, the scrolling easily keeps up with the ~25ms auto-repeat time. > Stefan -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 22 16:10:30 2015 Received: (at 20404) by debbugs.gnu.org; 22 Apr 2015 20:10:30 +0000 Received: from localhost ([127.0.0.1]:36809 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yl0yb-0002Jl-9U for submit@debbugs.gnu.org; Wed, 22 Apr 2015 16:10:29 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:53213) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yl0yY-0002Jc-ML for 20404@debbugs.gnu.org; Wed, 22 Apr 2015 16:10:27 -0400 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 60EE12088A for <20404@debbugs.gnu.org>; Wed, 22 Apr 2015 16:10:26 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Wed, 22 Apr 2015 16:10:26 -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=v6daW0yqD6cYv3Cc9gF3QeNq5nc=; b=nLJme jrITauA1HWqXc5a5ix+MjT3G5NA0TKZrpG1rGnUnhn2Sy8upT1ziY0pHKxw6ezzz wPeubBxeBAksPihtrHiTVvMTaqFw6o8z+OAwCReqPXAViSObhpyDA9+bi0AtbE8o pQ3vejBQd3n0WH8rFCfWF7UgJX2slWNyQriA44= X-Sasl-enc: 3YdY2jsG9ur7UMBqdxUBZgzZAyEK71cYGq6VGl9Fqh24 1429733425 Received: from thinkpad-t440p (unknown [2.163.86.218]) by mail.messagingengine.com (Postfix) with ESMTPA id 23770680097; Wed, 22 Apr 2015 16:10:24 -0400 (EDT) From: Tassilo Horn To: Stefan Monnier Subject: Re: bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time References: <87a8y0iji1.fsf@gnu.org> <20150422163110.68601.qmail@mail.muc.de> Date: Wed, 22 Apr 2015 22:10:21 +0200 In-Reply-To: (Stefan Monnier's message of "Wed, 22 Apr 2015 13:37:13 -0400") Message-ID: <87383rhqky.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-Debbugs-Envelope-To: 20404 Cc: Alan Mackenzie , 20404@debbugs.gnu.org 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: > [ OFFTOPIC: the bug report is not about performance but about > a functional bug in jit-lock-defer. ] > >> There's a solution (or, depending on your point of view, a workaround) >> for this. You're using Emacs-25, so set fast-but-imprecise-scrolling to >> t, or customize it (it's in customisation group "scrolling"). > > FWIW, on my machine, this doesn't make much difference: a single > "font-lock one screen's worth" takes much too long, so after that one > screen is displayed, Emacs takes a while catching up (with no display > at all in the mean time). Setting `fast-but-imprecise-scrolling' to t works quite nicely for me. Scrolling is indeed a bit bumpy but there are no noticeable hangs. And it's nice that the text scrolls by fontified. > So I recommend you try jit-lock-defer-time set to 0 instead of using > fast-but-imprecise-scrolling, and see if you like the resulting > behavior. This doesn't work for me. I get the same display freezes as with `jit-lock-defer-time' set to nil. I guess that's not how it's indended to be. Maybe keyboard events don't count as pending input? Bye, Tassilo From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 22 16:32:21 2015 Received: (at 20404) by debbugs.gnu.org; 22 Apr 2015 20:32:21 +0000 Received: from localhost ([127.0.0.1]:36817 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yl1Jk-0002pr-Jo for submit@debbugs.gnu.org; Wed, 22 Apr 2015 16:32:20 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:38040) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yl1Ji-0002pi-0c for 20404@debbugs.gnu.org; Wed, 22 Apr 2015 16:32:18 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id C3E28206A3 for <20404@debbugs.gnu.org>; Wed, 22 Apr 2015 16:32:17 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Wed, 22 Apr 2015 16:32:17 -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=GCcmwgYwBBKy7kLboyMl8bqXQPo=; b=IVi3s 7uk9U4oYVOG55bgfiQTWxLSx1L0qbbf7icWOk+S6D+wAv26FzH7M61sXoWn9bu1R gkQpailmKim++O1AbEIAj4YvLsBjHFaYB/arwO0th+IEwFavXGFJmlef/XmJwQS2 pIOtAwNXkajGku8SEO3zbH0vxxc5QL6nu7lyuw= X-Sasl-enc: +e/bz4iU5paT+K/jelCyHLT2mefiwRh6JuTp4pqZ9wOL 1429734737 Received: from thinkpad-t440p (unknown [2.163.86.218]) by mail.messagingengine.com (Postfix) with ESMTPA id 971A168006C; Wed, 22 Apr 2015 16:32:16 -0400 (EDT) From: Tassilo Horn To: Eli Zaretskii Subject: Re: bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time References: <87a8y0iji1.fsf@gnu.org> <837ft44fnf.fsf@gnu.org> Date: Wed, 22 Apr 2015 22:32:14 +0200 In-Reply-To: <837ft44fnf.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 22 Apr 2015 13:32:36 +0300") Message-ID: <87y4ljgb01.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-Debbugs-Envelope-To: 20404 Cc: 20404@debbugs.gnu.org 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: >> Another and even reproducible case is `report-emacs-bug'. It goes >> like this: >> >> 1. emacs -Q >> 2. eval my above settings in *scratch* >> 3. M-x report-emacs-bug >> >> The new message buffer is completely unfontified initially. As soon >> as you move point, font-lock kicks in and the header lines get their >> proper fontification. Or maybe it's the other way round, i.e., the >> buffer is created, then redisplayed, then the fontification takes >> place but no redisplay is performed thereafter. > > Sounds like the idle timer that is started by jit-lock-defer-time > never runs after the buffer is displayed. Indeed, that's the case. Or wait, it eventually runs but much later than `jit-lock-defer-time' defines. > Could it be that it already ran before the display? No. The bug report buffer is displayed first, and then it takes two or three seconds until the first jit-lock kicks in. And then the buffer will be redisplayed and appears fontified. I tested using this code: --8<---------------cut here---------------start------------->8--- (progn (setq jit-lock-defer-time 0.0312 jit-lock-stealth-nice 0.117 jit-lock-stealth-time 0.23) (require 'cl-lib) (defvar i 0) (advice-add 'jit-lock-deferred-fontify :before (lambda () (message "DEFERRED FONTIFY %s" (cl-incf i))))) --8<---------------cut here---------------end--------------->8--- Bye, Tassilo From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 22 16:53:10 2015 Received: (at 20404) by debbugs.gnu.org; 22 Apr 2015 20:53:10 +0000 Received: from localhost ([127.0.0.1]:36822 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yl1dt-0003IL-JL for submit@debbugs.gnu.org; Wed, 22 Apr 2015 16:53:10 -0400 Received: from mercure.iro.umontreal.ca ([132.204.24.67]:57480) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yl1dr-0003IC-1b for 20404@debbugs.gnu.org; Wed, 22 Apr 2015 16:53:07 -0400 Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 1958785004; Wed, 22 Apr 2015 16:53:05 -0400 (EDT) Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id E94DC1E5B8C; Wed, 22 Apr 2015 16:52:42 -0400 (EDT) Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848) id BAA55B40DC; Wed, 22 Apr 2015 16:52:42 -0400 (EDT) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time Message-ID: References: <87a8y0iji1.fsf@gnu.org> <20150422163110.68601.qmail@mail.muc.de> <20150422193204.GC4120@acm.fritz.box> Date: Wed, 22 Apr 2015 16:52:42 -0400 In-Reply-To: <20150422193204.GC4120@acm.fritz.box> (Alan Mackenzie's message of "Wed, 22 Apr 2015 19:32:04 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82, MC_TSTLAST 0.00) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca X-Spam-Status: No X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 20404 Cc: 20404@debbugs.gnu.org, Tassilo Horn 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: -2.3 (--) > How long is "too long"? Do you mean that, with > fast-but-imprecise-scrolling non-nil, jit-lock-defer-time nil, holding > down C-v, that there is no redisplay for several seconds? No, it's usually shorter than "several seconds", but it's only refreshed maybe twice a second (I use a repeat rate of 40/s) with a few waits that are longer than that. In contrast with jit-lock-defer-time set to 0, the scrolling is mostly smooth for me. > That would be suggesting that the time to scroll one screen (without > fontification) is longer than your auto-repeat interval, which > sounds implausible. It's not the case, indeed, no. [ Though, if I push the test with a sufficiently tall window (1600 vertical pixels, and a small enough font), I do get it to skip some redisplays even with font-lock-mode off. But that's also because my processor is slow ("Atom-Z530 @ 1.60GHz") and I compile with all kinds of extra debugging code. ] > No, I don't. ;-) What I see is somewhat jerky scrolling, mainly > unfontified, but with some fontification flashing on each screen some > short time (?10-100 milliseconds) before the next scroll. Hmm... interesting. I don't see the "some fontification flashing": for me it scrolls unfontified until I stop scrolling (at which point it's shown immediately fontified). I guess in your case, your machine is just fast enough to perform the fontification every few steps, whereas mine is always "trying to catch up". Maybe for you to see the same behavior as I see, you'd have to use a non-0 setting for jit-lock-defer-time to try and prevent the occasional deferred fontification (probably using a defer-time that's just above the repeat-time of your keyboard), but my hack (which basically disables the deferring when there's no pending input) would need to be tweaked (it treats timer==0 specially). > What I see with fast-but-imprecise-scrolling is somewhat jerky scrolling, > but each displayed screen being fully fontified. Yes, the always-fontified display is clearly the obvious advantage of fast-but-imprecise-scrolling. I'm personally bothered by the jerkiness of the scrolling, but if jit-lock-defer-time also gives you jerky scrolling, then clearly it's a loser. > Also, when I attempt to disable jit-lock-defer-time (through the > customisation interface) the jit-lock-defer-timer keeps running, and the > "defer" mechanism keeps running with it. This seems worth a bug report > in its own right. Yup, sounds like it deserves its own bug report. > I don't understand how what you're seeing is so bad. I thought you had a > powerful workstation, a class above a typical PC, and that you had your > auto-repeat rate at a conservative figure (25 or 30 per second) rather > than the insane rate (~40 per second) I have. I have various machines, but my desktops are a Fit-PC2 (at work) and a AMD E-350 (at home). So "powerful workstation" is not exactly the term I would employ. This said, "insane" is not the term I'd use to describe 40 repetitions per seconds either. > I have a 5 year old machine, not a blazingly fast super-modern one, > and my window is 64 lines deep. Right windows are typically between 65 and 80 lines tall, as well. Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 22 17:33:22 2015 Received: (at 20404) by debbugs.gnu.org; 22 Apr 2015 21:33:22 +0000 Received: from localhost ([127.0.0.1]:36843 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yl2Gn-0004E7-TO for submit@debbugs.gnu.org; Wed, 22 Apr 2015 17:33:22 -0400 Received: from mtaout26.012.net.il ([80.179.55.182]:41491) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yl2Gl-0004Dt-JV for 20404@debbugs.gnu.org; Wed, 22 Apr 2015 17:33:20 -0400 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NN800B00927OD00@mtaout26.012.net.il> for 20404@debbugs.gnu.org; Thu, 23 Apr 2015 00:34:49 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NN800ANO9A0OI10@mtaout26.012.net.il>; Thu, 23 Apr 2015 00:34:49 +0300 (IDT) Date: Thu, 23 Apr 2015 00:33:12 +0300 From: Eli Zaretskii Subject: Re: bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time In-reply-to: <87383rhqky.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: Tassilo Horn Message-id: <83egnb3l2f.fsf@gnu.org> References: <87a8y0iji1.fsf@gnu.org> <20150422163110.68601.qmail@mail.muc.de> <87383rhqky.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 20404 Cc: acm@muc.de, monnier@IRO.UMontreal.CA, 20404@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii 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: Wed, 22 Apr 2015 22:10:21 +0200 > Cc: Alan Mackenzie , 20404@debbugs.gnu.org > > Maybe keyboard events don't count as pending input? ??? Of course they do. From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 22 17:41:08 2015 Received: (at 20404) by debbugs.gnu.org; 22 Apr 2015 21:41:08 +0000 Received: from localhost ([127.0.0.1]:36847 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yl2OJ-0004Oi-RK for submit@debbugs.gnu.org; Wed, 22 Apr 2015 17:41:08 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:44916) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yl2OH-0004O6-1q for 20404@debbugs.gnu.org; Wed, 22 Apr 2015 17:41:06 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NN800C009CWN300@a-mtaout22.012.net.il> for 20404@debbugs.gnu.org; Thu, 23 Apr 2015 00:39:24 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NN800CFO9HOHE60@a-mtaout22.012.net.il>; Thu, 23 Apr 2015 00:39:24 +0300 (IDT) Date: Thu, 23 Apr 2015 00:39:23 +0300 From: Eli Zaretskii Subject: Re: bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time In-reply-to: <87y4ljgb01.fsf_-_@gnu.org> X-012-Sender: halo1@inter.net.il To: Tassilo Horn Message-id: <83bnif3ks4.fsf@gnu.org> References: <87a8y0iji1.fsf@gnu.org> <837ft44fnf.fsf@gnu.org> <87y4ljgb01.fsf_-_@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 20404 Cc: 20404@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii 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: 20404@debbugs.gnu.org > Date: Wed, 22 Apr 2015 22:32:14 +0200 > > > Sounds like the idle timer that is started by jit-lock-defer-time > > never runs after the buffer is displayed. > > Indeed, that's the case. Or wait, it eventually runs but much later > than `jit-lock-defer-time' defines. > > > Could it be that it already ran before the display? > > No. The bug report buffer is displayed first, and then it takes two or > three seconds until the first jit-lock kicks in. And then the buffer > will be redisplayed and appears fontified. So you are saying that something prevents the timer to run at the prescribed time? I suggest to add trace printf's in the code that traverses the idle-timers' list, and see why this timer doesn't run on time. From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 23 00:15:33 2015 Received: (at 20404) by debbugs.gnu.org; 23 Apr 2015 04:15:33 +0000 Received: from localhost ([127.0.0.1]:36965 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yl8Y0-0004w9-GS for submit@debbugs.gnu.org; Thu, 23 Apr 2015 00:15:32 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:57478) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yl8Xy-0004vz-6E for 20404@debbugs.gnu.org; Thu, 23 Apr 2015 00:15:31 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 8F0DE205AD for <20404@debbugs.gnu.org>; Thu, 23 Apr 2015 00:15:29 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Thu, 23 Apr 2015 00:15:29 -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=A8QQBnW91kNIQln5R7PhsrCitsE=; b=rXQ9G RaAv/pRhBI6T64YPKLpp00zOZswLQo+TP2O4BqOJ2UlceoKEO04KvZsISzUvz37i zERRlGfWeBQg6gbD4yQ9cSB/t7r2jkT0z/jjC58P3229g5wLq7S8emx/wUf65x4G 6h1QuJnFECovdJ3gyMXYS0Me9vUGGQUEOlo+zE= X-Sasl-enc: 5rZFDVxaWbypsVdYmxIN/InXFppQTs0ufHsTeeYaHfex 1429762529 Received: from thinkpad-t440p (unknown [2.162.110.201]) by mail.messagingengine.com (Postfix) with ESMTPA id 655F2C0001B; Thu, 23 Apr 2015 00:15:28 -0400 (EDT) From: Tassilo Horn To: Eli Zaretskii Subject: Re: bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time References: <87a8y0iji1.fsf@gnu.org> <20150422163110.68601.qmail@mail.muc.de> <87383rhqky.fsf@gnu.org> <83egnb3l2f.fsf@gnu.org> Date: Thu, 23 Apr 2015 06:15:25 +0200 In-Reply-To: <83egnb3l2f.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 23 Apr 2015 00:33:12 +0300") Message-ID: <877ft3cwf6.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-Debbugs-Envelope-To: 20404 Cc: acm@muc.de, monnier@IRO.UMontreal.CA, 20404@debbugs.gnu.org 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: >> From: Tassilo Horn >> Date: Wed, 22 Apr 2015 22:10:21 +0200 >> Cc: Alan Mackenzie , 20404@debbugs.gnu.org >> >> Maybe keyboard events don't count as pending input? > > ??? Of course they do. Well, then jit-lock-defer-time == 0 doesn't work here as documented. It doesn't seem to defer anything although there must be dozens or hundreds of pending keyboard events when I press and hold `C-v'. Bye, Tassilo From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 23 01:59:20 2015 Received: (at 20404) by debbugs.gnu.org; 23 Apr 2015 05:59:20 +0000 Received: from localhost ([127.0.0.1]:36980 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlAAR-0007Pz-TN for submit@debbugs.gnu.org; Thu, 23 Apr 2015 01:59:20 -0400 Received: from deliver.uni-koblenz.de ([141.26.64.15]:54136) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlAAP-0007Pm-2x for 20404@debbugs.gnu.org; Thu, 23 Apr 2015 01:59:18 -0400 Received: from thinkpad-t440p (dhcp18.uni-koblenz.de [141.26.71.18]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by deliver.uni-koblenz.de (Postfix) with ESMTPSA id DAC171A854C; Thu, 23 Apr 2015 07:59:15 +0200 (CEST) From: Tassilo Horn To: Eli Zaretskii Subject: Re: bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time References: <87a8y0iji1.fsf@gnu.org> <837ft44fnf.fsf@gnu.org> <87y4ljgb01.fsf_-_@gnu.org> <83bnif3ks4.fsf@gnu.org> Date: Thu, 23 Apr 2015 07:59:15 +0200 In-Reply-To: <83bnif3ks4.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 23 Apr 2015 00:39:23 +0300") Message-ID: <87oamfwfkc.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: -1.3 (-) X-Debbugs-Envelope-To: 20404 Cc: 20404@debbugs.gnu.org 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 (-) Eli Zaretskii writes: >> > Sounds like the idle timer that is started by jit-lock-defer-time >> > never runs after the buffer is displayed. >> >> Indeed, that's the case. Or wait, it eventually runs but much later >> than `jit-lock-defer-time' defines. >> >> > Could it be that it already ran before the display? >> >> No. The bug report buffer is displayed first, and then it takes two >> or three seconds until the first jit-lock kicks in. And then the >> buffer will be redisplayed and appears fontified. > > So you are saying that something prevents the timer to run at the > prescribed time? That seems to be the case. > I suggest to add trace printf's in the code that traverses the > idle-timers' list, and see why this timer doesn't run on time. That would be static struct timespec timer_check_2 (Lisp_Object timers, Lisp_Object idle_timers) right? So first I wanted to see if the deferred font-lock timer gets selected as being ripe in the first place. But I already failed with that; emacs now dumps core. --8<---------------cut here---------------start------------->8--- diff --git a/src/keyboard.c b/src/keyboard.c index 068a47c..6231747 100644 --- a/src/keyboard.c +++ b/src/keyboard.c @@ -4419,6 +4419,8 @@ timer_check_2 (Lisp_Object timers, Lisp_Object idle_timers) Lisp_Object chosen_timer; struct gcpro gcpro1; + printf ("timer_check2 ()"); + nexttime = invalid_timespec (); chosen_timer = Qnil; @@ -4513,6 +4515,10 @@ timer_check_2 (Lisp_Object timers, Lisp_Object idle_timers) idle_timers = XCDR (idle_timers); difference = idle_timer_difference; ripe = idle_timer_ripe; + if (ripe) + { + printf("Idle timer calling %s is ripe.", AREF (5, chosen_timer)); + } } /* If timer is ripe, run it if it hasn't been run. */ --8<---------------cut here---------------end--------------->8--- I think the problem is that the AREF returns the timer's function or maybe the symbol whose function definition is the timer's function. In any case, that's not a char* required by printf's %s. How do I get the function's name in order to print that? Bye, Tassilo From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 23 02:14:19 2015 Received: (at 20404) by debbugs.gnu.org; 23 Apr 2015 06:14:19 +0000 Received: from localhost ([127.0.0.1]:36984 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlAOw-0007mE-Ms for submit@debbugs.gnu.org; Thu, 23 Apr 2015 02:14:19 -0400 Received: from mtaout26.012.net.il ([80.179.55.182]:59478) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlAOv-0007m2-6a for 20404@debbugs.gnu.org; Thu, 23 Apr 2015 02:14:18 -0400 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NN800C00XBB3700@mtaout26.012.net.il> for 20404@debbugs.gnu.org; Thu, 23 Apr 2015 09:15:46 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NN8007TMXEAUP30@mtaout26.012.net.il>; Thu, 23 Apr 2015 09:15:46 +0300 (IDT) Date: Thu, 23 Apr 2015 09:14:10 +0300 From: Eli Zaretskii Subject: Re: bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time In-reply-to: <87oamfwfkc.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: Tassilo Horn Message-id: <83a8xz2wy5.fsf@gnu.org> References: <87a8y0iji1.fsf@gnu.org> <837ft44fnf.fsf@gnu.org> <87y4ljgb01.fsf_-_@gnu.org> <83bnif3ks4.fsf@gnu.org> <87oamfwfkc.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 20404 Cc: 20404@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii 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: 20404@debbugs.gnu.org > Date: Thu, 23 Apr 2015 07:59:15 +0200 > > Eli Zaretskii writes: > > > So you are saying that something prevents the timer to run at the > > prescribed time? > > That seems to be the case. It can also be that Emacs doesn't become idle for some reason. > > I suggest to add trace printf's in the code that traverses the > > idle-timers' list, and see why this timer doesn't run on time. > > That would be > > static struct timespec > timer_check_2 (Lisp_Object timers, Lisp_Object idle_timers) > > right? Yes. > + if (ripe) > + { > + printf("Idle timer calling %s is ripe.", AREF (5, chosen_timer)); > + } > } > > /* If timer is ripe, run it if it hasn't been run. */ > --8<---------------cut here---------------end--------------->8--- > > I think the problem is that the AREF returns the timer's function or > maybe the symbol whose function definition is the timer's function. Yes, you cannon printf a Lisp object with %s. > How do I get the function's name in order to print that? Try SDATA (SYMBOL_NAME (AREF (5, chosen_timer))). From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 23 02:36:06 2015 Received: (at 20404) by debbugs.gnu.org; 23 Apr 2015 06:36:06 +0000 Received: from localhost ([127.0.0.1]:37008 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlAk1-0008IJ-M7 for submit@debbugs.gnu.org; Thu, 23 Apr 2015 02:36:05 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:58729) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlAjz-0008Hn-Ey for 20404@debbugs.gnu.org; Thu, 23 Apr 2015 02:36:04 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NN800700Y27FL00@a-mtaout21.012.net.il> for 20404@debbugs.gnu.org; Thu, 23 Apr 2015 09:35:56 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NN8007ETYBWBLA0@a-mtaout21.012.net.il>; Thu, 23 Apr 2015 09:35:56 +0300 (IDT) Date: Thu, 23 Apr 2015 09:35:57 +0300 From: Eli Zaretskii Subject: Re: bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time In-reply-to: <877ft3cwf6.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: Tassilo Horn Message-id: <83618n2vxu.fsf@gnu.org> References: <87a8y0iji1.fsf@gnu.org> <20150422163110.68601.qmail@mail.muc.de> <87383rhqky.fsf@gnu.org> <83egnb3l2f.fsf@gnu.org> <877ft3cwf6.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 20404 Cc: acm@muc.de, monnier@IRO.UMontreal.CA, 20404@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii 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, acm@muc.de, 20404@debbugs.gnu.org > Date: Thu, 23 Apr 2015 06:15:25 +0200 > > Eli Zaretskii writes: > > >> From: Tassilo Horn > >> Date: Wed, 22 Apr 2015 22:10:21 +0200 > >> Cc: Alan Mackenzie , 20404@debbugs.gnu.org > >> > >> Maybe keyboard events don't count as pending input? > > > > ??? Of course they do. > > Well, then jit-lock-defer-time == 0 doesn't work here as documented. It > doesn't seem to defer anything although there must be dozens or hundreds > of pending keyboard events when I press and hold `C-v'. I think I explained this back when there was a very long discussion of Alan's fast-but-imprecise-scrolling patch. From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 23 03:54:35 2015 Received: (at 20404) by debbugs.gnu.org; 23 Apr 2015 07:54:35 +0000 Received: from localhost ([127.0.0.1]:37079 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlBxy-0003Br-BC for submit@debbugs.gnu.org; Thu, 23 Apr 2015 03:54:34 -0400 Received: from mtaout29.012.net.il ([80.179.55.185]:51877) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlBxu-0003BO-Gt for 20404@debbugs.gnu.org; Thu, 23 Apr 2015 03:54:32 -0400 Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NN900D001JCEW00@mtaout29.012.net.il> for 20404@debbugs.gnu.org; Thu, 23 Apr 2015 10:52:51 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NN9003FB1W367A0@mtaout29.012.net.il>; Thu, 23 Apr 2015 10:52:51 +0300 (IDT) Date: Thu, 23 Apr 2015 10:54:24 +0300 From: Eli Zaretskii Subject: Re: bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time In-reply-to: <87a8y0iji1.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: Tassilo Horn Message-id: <83383r2sb3.fsf@gnu.org> References: <87a8y0iji1.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 20404 Cc: 20404@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii 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: Wed, 22 Apr 2015 11:45:42 +0200 > > I use the settings > > (setq jit-lock-defer-time 0.0312 > jit-lock-stealth-nice 0.117 > jit-lock-stealth-time 0.23) > > to speed up scrolling in large buffers with complex font-lock rules. > That basically works nice. However, quite often I'm faced with buffers > that are not fontified before I do something, e.g., move point. > > This frequently happens when installing/upgrading packages with the > package manager. That shows the buffer containing the byte-compliation > messages with fontified warnings and errors. Every second time or so, > I'm faced with a completely unfontified buffer that gets fontified only > after selecting the window showing the buffer. > > Another and even reproducible case is `report-emacs-bug'. It goes like > this: > > 1. emacs -Q > 2. eval my above settings in *scratch* > 3. M-x report-emacs-bug > > The new message buffer is completely unfontified initially. I've reproduced this recipe. The fontification happens about 2.5 sec after the buffer is initially displayed. I've noticed that the cursor also doesn't blink during these few seconds, which seems to imply that Emacs simply doesn't "become idle" during that time, or maybe doesn't run _any_ idle timers during that time for some other reason. Btw, it is enough to set jit-lock-defer-time to something non-zero, to have this effect; the other 2 customizations seem not to affect this. From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 23 04:37:06 2015 Received: (at 20404) by debbugs.gnu.org; 23 Apr 2015 08:37:06 +0000 Received: from localhost ([127.0.0.1]:37107 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlCd7-0004Rw-Oy for submit@debbugs.gnu.org; Thu, 23 Apr 2015 04:37:06 -0400 Received: from deliver.uni-koblenz.de ([141.26.64.15]:59102) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlCd4-0004RU-5K for 20404@debbugs.gnu.org; Thu, 23 Apr 2015 04:37:03 -0400 Received: from thinkpad-t440p (dhcp18.uni-koblenz.de [141.26.71.18]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by deliver.uni-koblenz.de (Postfix) with ESMTPSA id 40EB51A8246; Thu, 23 Apr 2015 10:36:59 +0200 (CEST) From: Tassilo Horn To: Eli Zaretskii Subject: Re: bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time References: <87a8y0iji1.fsf@gnu.org> <837ft44fnf.fsf@gnu.org> <87y4ljgb01.fsf_-_@gnu.org> <83bnif3ks4.fsf@gnu.org> <87oamfwfkc.fsf@gnu.org> <83a8xz2wy5.fsf@gnu.org> Date: Thu, 23 Apr 2015 10:36:59 +0200 In-Reply-To: <83a8xz2wy5.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 23 Apr 2015 09:14:10 +0300") Message-ID: <87k2x3w89g.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: -1.3 (-) X-Debbugs-Envelope-To: 20404 Cc: 20404@debbugs.gnu.org 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 (-) Eli Zaretskii writes: >> From: Tassilo Horn >> Cc: 20404@debbugs.gnu.org >> Date: Thu, 23 Apr 2015 07:59:15 +0200 >> >> Eli Zaretskii writes: >> >> > So you are saying that something prevents the timer to run at the >> > prescribed time? >> >> That seems to be the case. > > It can also be that Emacs doesn't become idle for some reason. > >> > I suggest to add trace printf's in the code that traverses the >> > idle-timers' list, and see why this timer doesn't run on time. >> >> That would be >> >> static struct timespec >> timer_check_2 (Lisp_Object timers, Lisp_Object idle_timers) >> >> right? > > Yes. > >> + if (ripe) >> + { >> + printf("Idle timer calling %s is ripe.", AREF (5, chosen_timer)); >> + } >> } >> >> /* If timer is ripe, run it if it hasn't been run. */ >> --8<---------------cut here---------------end--------------->8--- >> >> I think the problem is that the AREF returns the timer's function or >> maybe the symbol whose function definition is the timer's function. > > Yes, you cannon printf a Lisp object with %s. > >> How do I get the function's name in order to print that? > > Try SDATA (SYMBOL_NAME (AREF (5, chosen_timer))). That works although you have to add more checks for lambdas, etc. So now I use this: --8<---------------cut here---------------start------------->8--- diff --git a/src/keyboard.c b/src/keyboard.c index 068a47c..fe906b0 100644 --- a/src/keyboard.c +++ b/src/keyboard.c @@ -4410,6 +4410,24 @@ decode_timer (Lisp_Object timer, struct timespec *result) In that case we return 0 to indicate that a new timer_check_2 call should be done. */ +void print_timer(Lisp_Object chosen_timer, const char* kind) { + const char* timer_fn_name = ""; + const Lisp_Object fn = AREF (chosen_timer, 5); + if (fn) { + timer_fn_name = ""; + if (SYMBOLP (fn)) { + const Lisp_Object sn = SYMBOL_NAME (fn); + if (sn) { + timer_fn_name = SDATA (sn); + } + } + } + printf("%s timer calling %s is ripe.\n", + kind, timer_fn_name); +} + +int myCounter = 0; + static struct timespec timer_check_2 (Lisp_Object timers, Lisp_Object idle_timers) { @@ -4419,6 +4437,8 @@ timer_check_2 (Lisp_Object timers, Lisp_Object idle_timers) Lisp_Object chosen_timer; struct gcpro gcpro1; + printf ("timer_check2 () %d\n", myCounter++); + nexttime = invalid_timespec (); chosen_timer = Qnil; @@ -4506,6 +4526,10 @@ timer_check_2 (Lisp_Object timers, Lisp_Object idle_timers) timers = XCDR (timers); difference = timer_difference; ripe = timer_ripe; + if (ripe) + { + print_timer (chosen_timer, "normal"); + } } else { @@ -4513,6 +4537,10 @@ timer_check_2 (Lisp_Object timers, Lisp_Object idle_timers) idle_timers = XCDR (idle_timers); difference = idle_timer_difference; ripe = idle_timer_ripe; + if (ripe) + { + print_timer (chosen_timer, "idle"); + } } /* If timer is ripe, run it if it hasn't been run. */ --8<---------------cut here---------------end--------------->8--- And when doing `M-x report-emacs-bug RET bug summary RET`, that's the output in the period in which the buffer is not fontified. --8<---------------cut here---------------start------------->8--- normal timer calling blink-cursor-timer-function is ripe. timer_check2 () 1329 timer_check2 () 1330 timer_check2 () 1331 timer_check2 () 1332 timer_check2 () 1333 timer_check2 () 1334 timer_check2 () 1335 timer_check2 () 1336 timer_check2 () 1337 timer_check2 () 1338 timer_check2 () 1339 timer_check2 () 1340 timer_check2 () 1341 timer_check2 () 1343 timer_check2 () 1344 timer_check2 () 1345 timer_check2 () 1346 timer_check2 () 1348 timer_check2 () 1349 timer_check2 () 1350 timer_check2 () 1351 timer_check2 () 1352 timer_check2 () 1353 timer_check2 () 1354 timer_check2 () 1355 timer_check2 () 1356 timer_check2 () 1357 timer_check2 () 1358 timer_check2 () 1359 timer_check2 () 1360 timer_check2 () 1361 timer_check2 () 1362 timer_check2 () 1363 timer_check2 () 1364 timer_check2 () 1365 timer_check2 () 1366 timer_check2 () 1367 idle timer calling jit-lock-deferred-fontify is ripe. --8<---------------cut here---------------end--------------->8--- So as you can see, in that period there are many calls of timer_check2() but none of them select some timer as being ripe. Neither normal nor idle timers. That is, the problem isn't really about deferred fontification but about timer's not being selected for execution. That is, for example the cursor doesn't blink, too, which is another idle timer that's not run in the period. Here's the output if I also `trace-redisplay'. --8<---------------cut here---------------start------------->8--- redisplay_internal 0 trying display optimization 1 0x12b1c30 ( *Minibuf-1*): optimization 1 timer_check2 () 4941 timer_check2 () 4942 timer_check2 () 4943 timer_check2 () 4944 timer_check2 () 4945 timer_check2 () 4946 redisplay_preserve_echo_area (2) redisplay_internal 0 0x12b0c20 (*unsent mail to bug-gnu-emacs@gnu.org*): same window start 0x12b0c20 (*unsent mail to bug-gnu-emacs@gnu.org*): 1 0x12f8d60 (*Bug Help*): same window start 0x12f8d60 (*Bug Help*): 1 timer_check2 () 4947 redisplay_internal 0 0x12b0c20 (*unsent mail to bug-gnu-emacs@gnu.org*): same window start 0x12b0c20 (*unsent mail to bug-gnu-emacs@gnu.org*): 1 0x12f8d60 (*Bug Help*): same window start 0x12f8d60 (*Bug Help*): 1 timer_check2 () 4948 timer_check2 () 4949 timer_check2 () 4950 timer_check2 () 4951 timer_check2 () 4952 timer_check2 () 4953 timer_check2 () 4954 timer_check2 () 4955 timer_check2 () 4956 timer_check2 () 4957 timer_check2 () 4958 timer_check2 () 4959 timer_check2 () 4960 timer_check2 () 4961 timer_check2 () 4962 timer_check2 () 4963 timer_check2 () 4964 timer_check2 () 4965 timer_check2 () 4966 timer_check2 () 4967 timer_check2 () 4968 timer_check2 () 4969 timer_check2 () 4970 timer_check2 () 4971 timer_check2 () 4972 timer_check2 () 4973 timer_check2 () 4974 timer_check2 () 4975 timer_check2 () 4976 timer_check2 () 4977 redisplay_internal 0 timer_check2 () 4978 timer_check2 () 4979 timer_check2 () 4980 timer_check2 () 4981 timer_check2 () 4982 timer_check2 () 4983 timer_check2 () 4984 redisplay_internal 0 timer_check2 () 4985 timer_check2 () 4986 timer_check2 () 4987 timer_check2 () 4988 idle timer calling jit-lock-deferred-fontify is ripe. timer_check2 () 4989 timer_check2 () 4990 timer_check2 () 4991 redisplay_preserve_echo_area (2) redisplay_internal 0 0x12b0c20 (*unsent mail to bug-gnu-emacs@gnu.org*): same window start 0x12b0c20 (*unsent mail to bug-gnu-emacs@gnu.org*): 1 --8<---------------cut here---------------end--------------->8--- HTH, Tassilo From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 23 04:38:26 2015 Received: (at 20404) by debbugs.gnu.org; 23 Apr 2015 08:38:27 +0000 Received: from localhost ([127.0.0.1]:37111 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlCeP-0004U4-Tw for submit@debbugs.gnu.org; Thu, 23 Apr 2015 04:38:26 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:64871) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlCeN-0004Tn-AH for 20404@debbugs.gnu.org; Thu, 23 Apr 2015 04:38:24 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NN9007003M5OE00@a-mtaout21.012.net.il> for 20404@debbugs.gnu.org; Thu, 23 Apr 2015 11:38:16 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NN9007LO3ZQOR00@a-mtaout21.012.net.il>; Thu, 23 Apr 2015 11:38:15 +0300 (IDT) Date: Thu, 23 Apr 2015 11:38:16 +0300 From: Eli Zaretskii Subject: Re: bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time In-reply-to: <83383r2sb3.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: tsdh@gnu.org Message-id: <831tjb2q9z.fsf@gnu.org> References: <87a8y0iji1.fsf@gnu.org> <83383r2sb3.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 20404 Cc: 20404@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii 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, 23 Apr 2015 10:54:24 +0300 > From: Eli Zaretskii > Cc: 20404@debbugs.gnu.org > > > 1. emacs -Q > > 2. eval my above settings in *scratch* > > 3. M-x report-emacs-bug > > > > The new message buffer is completely unfontified initially. > > I've reproduced this recipe. The fontification happens about 2.5 sec > after the buffer is initially displayed. I've noticed that the cursor > also doesn't blink during these few seconds, which seems to imply that > Emacs simply doesn't "become idle" during that time, or maybe doesn't > run _any_ idle timers during that time for some other reason. > > Btw, it is enough to set jit-lock-defer-time to something non-zero, to > have this effect; the other 2 customizations seem not to affect this. Moreover, here's what seems to be a much simpler recipe that shows the underlying problem: emacs -Q M-x blink-cursor-mode RET M-x blink-cursor-mode RET And note that after the second "M-x blink-cursor-mode RET", which turns ON the blinking, Emacs waits for about the same 2 sec before it actually starts blinking. And here's why: _any_ command that goes through execute-extended-command will run this code: (when suggest-key-bindings (sit-for (cond ((zerop (length (current-message))) 0) ((numberp suggest-key-bindings) suggest-key-bindings) (t 2)))))) The default value of suggest-key-bindings is t, so this means we _always_ sit-for 2 seconds, unless the echo area shows nothing (a rare situation in Emacs). When Emacs is parked inside sit-for, it doesn't become idle, I think for good reasons. So the idle timers will not run until those 2 sec have expired, or some input becomes available. And indeed setting suggest-key-bindings to nil causes the buffer displayed by report-emacs-bug to become fontified almost immediately, under Tassilo's settings of jit-lock-defer-time. The upshot of all this is that any command that displays a buffer via execute-extended-command and also says something in the echo area, will always delay JIT deferred fontifications (and any other features that run via idle timers) for at least 2 sec. From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 23 04:38:38 2015 Received: (at 20404) by debbugs.gnu.org; 23 Apr 2015 08:38:38 +0000 Received: from localhost ([127.0.0.1]:37114 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlCec-0004UT-03 for submit@debbugs.gnu.org; Thu, 23 Apr 2015 04:38:38 -0400 Received: from deliver.uni-koblenz.de ([141.26.64.15]:59189) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlCea-0004UL-BM for 20404@debbugs.gnu.org; Thu, 23 Apr 2015 04:38:36 -0400 Received: from thinkpad-t440p (dhcp18.uni-koblenz.de [141.26.71.18]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by deliver.uni-koblenz.de (Postfix) with ESMTPSA id 0B8111A824F; Thu, 23 Apr 2015 10:38:36 +0200 (CEST) From: Tassilo Horn To: Eli Zaretskii Subject: Re: bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time References: <87a8y0iji1.fsf@gnu.org> <83383r2sb3.fsf@gnu.org> Date: Thu, 23 Apr 2015 10:38:35 +0200 In-Reply-To: <83383r2sb3.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 23 Apr 2015 10:54:24 +0300") Message-ID: <87fv7rw86s.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: -1.3 (-) X-Debbugs-Envelope-To: 20404 Cc: 20404@debbugs.gnu.org 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 (-) Eli Zaretskii writes: > I've reproduced this recipe. The fontification happens about 2.5 sec > after the buffer is initially displayed. I've noticed that the cursor > also doesn't blink during these few seconds, which seems to imply that > Emacs simply doesn't "become idle" during that time, or maybe doesn't > run _any_ idle timers during that time for some other reason. It doesn't run _any_ timers, no matter if normal or idle. See my other mail which also includes redisplay traces. > Btw, it is enough to set jit-lock-defer-time to something non-zero, to > have this effect; the other 2 customizations seem not to affect this. Right. Bye, Tassilo From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 23 05:04:47 2015 Received: (at 20404) by debbugs.gnu.org; 23 Apr 2015 09:04:47 +0000 Received: from localhost ([127.0.0.1]:37124 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlD3u-000564-Ic for submit@debbugs.gnu.org; Thu, 23 Apr 2015 05:04:46 -0400 Received: from deliver.uni-koblenz.de ([141.26.64.15]:59816) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlD3s-00055v-9r for 20404@debbugs.gnu.org; Thu, 23 Apr 2015 05:04:45 -0400 Received: from thinkpad-t440p (dhcp18.uni-koblenz.de [141.26.71.18]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by deliver.uni-koblenz.de (Postfix) with ESMTPSA id 00A981A83C5; Thu, 23 Apr 2015 11:04:43 +0200 (CEST) From: Tassilo Horn To: Eli Zaretskii Subject: Re: bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time References: <87a8y0iji1.fsf@gnu.org> <83383r2sb3.fsf@gnu.org> <831tjb2q9z.fsf@gnu.org> Date: Thu, 23 Apr 2015 11:04:43 +0200 In-Reply-To: <831tjb2q9z.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 23 Apr 2015 11:38:16 +0300") Message-ID: <87bnifw6z8.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: -1.3 (-) X-Debbugs-Envelope-To: 20404 Cc: 20404@debbugs.gnu.org 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 (-) Eli Zaretskii writes: > And here's why: _any_ command that goes through > execute-extended-command will run this code: > > (when suggest-key-bindings > (sit-for (cond > ((zerop (length (current-message))) 0) > ((numberp suggest-key-bindings) suggest-key-bindings) > (t 2)))))) > > The default value of suggest-key-bindings is t, so this means we > _always_ sit-for 2 seconds, unless the echo area shows nothing (a rare > situation in Emacs). When Emacs is parked inside sit-for, it doesn't > become idle, I think for good reasons. So the idle timers will not > run until those 2 sec have expired, or some input becomes available. Oh, yes, this explains things. > And indeed setting suggest-key-bindings to nil causes the buffer > displayed by report-emacs-bug to become fontified almost immediately, > under Tassilo's settings of jit-lock-defer-time. Confirmed. Hm, sometimes I actually like `suggest-key-bindings' namely whenever it tells that I could have used `C-x ' instead of `M-x ...'. But I don't like its suggestions to use `M-x fi-fi' instead of `M-x find-file'. I totally agree that sometimes there should be messages that should stick around for a given amount of time but using `sit-for` to stop the world turning as a whole seems like a bit overkill. Maybe such sticky messages could be shown in the `header-line' and then be removed by a timer. But of course, what should one do if the header-line is already in use? > The upshot of all this is that any command that displays a buffer via > execute-extended-command and also says something in the echo area, > will always delay JIT deferred fontifications (and any other features > that run via idle timers) for at least 2 sec. But how does that explain the occassionally non-fontified compile buffers I get during package upgrades/installs? Those don't go through `execute-extended-command'. But compile.el has some own `sit-for' invocations that might delay timers. Bye, Tassilo From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 23 05:17:00 2015 Received: (at 20404) by debbugs.gnu.org; 23 Apr 2015 09:17:00 +0000 Received: from localhost ([127.0.0.1]:37138 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlDFk-0005PH-1l for submit@debbugs.gnu.org; Thu, 23 Apr 2015 05:17:00 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:53635) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlDFh-0005P1-DO for 20404@debbugs.gnu.org; Thu, 23 Apr 2015 05:16:58 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NN900H005MM5T00@a-mtaout22.012.net.il> for 20404@debbugs.gnu.org; Thu, 23 Apr 2015 12:16:51 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NN900HAU5S24S30@a-mtaout22.012.net.il>; Thu, 23 Apr 2015 12:16:51 +0300 (IDT) Date: Thu, 23 Apr 2015 12:16:51 +0300 From: Eli Zaretskii Subject: Re: bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time In-reply-to: <87bnifw6z8.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: Tassilo Horn Message-id: <83zj5z19x8.fsf@gnu.org> References: <87a8y0iji1.fsf@gnu.org> <83383r2sb3.fsf@gnu.org> <831tjb2q9z.fsf@gnu.org> <87bnifw6z8.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 20404 Cc: 20404@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii 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: 20404@debbugs.gnu.org > Date: Thu, 23 Apr 2015 11:04:43 +0200 > > Eli Zaretskii writes: > > > And here's why: _any_ command that goes through > > execute-extended-command will run this code: > > > > (when suggest-key-bindings > > (sit-for (cond > > ((zerop (length (current-message))) 0) > > ((numberp suggest-key-bindings) suggest-key-bindings) > > (t 2)))))) > > > > The default value of suggest-key-bindings is t, so this means we > > _always_ sit-for 2 seconds, unless the echo area shows nothing (a rare > > situation in Emacs). When Emacs is parked inside sit-for, it doesn't > > become idle, I think for good reasons. So the idle timers will not > > run until those 2 sec have expired, or some input becomes available. > > Oh, yes, this explains things. This problem doesn't exist in Emacs 24.5, it only happens on master. And the reason seems to be the change in execute-extended-command: Emacs 24 only calls sit-for when the command actually _has_ a key binding: (when binding ;; But first wait, and skip the message if there is input. (let* ((waited ;; If this command displayed something in the echo area; ;; wait a few seconds, then display our suggestion message. (sit-for (cond ((zerop (length (current-message))) 0) ((numberp suggest-key-bindings) suggest-key-bindings) (t 2))))) On master, we wait unconditionally (and then wait some more if we actually show the suggested key binding, but that happens only once per given command). So perhaps some small change there, which removes this unnecessary unconditional wait whenever possible could solve the issue with jit-lock-defer-time and other similar idle timers. > Maybe such sticky messages could be shown in the `header-line' and then > be removed by a timer. But of course, what should one do if the > header-line is already in use? And in addition, this will cause an unpleasant redisplay of the current window, something that display in the echo area avoids. > But how does that explain the occassionally non-fontified compile > buffers I get during package upgrades/installs? Those don't go through > `execute-extended-command'. But compile.el has some own `sit-for' > invocations that might delay timers. Yes, something similar. If you can reproduce these problems at will, I can tell how to figure out which code caused the delay, similarly to what I did to figure out the problem with execute-extended-command. From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 23 09:40:22 2015 Received: (at 20404) by debbugs.gnu.org; 23 Apr 2015 13:40:22 +0000 Received: from localhost ([127.0.0.1]:37236 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlHMb-0004Vi-61 for submit@debbugs.gnu.org; Thu, 23 Apr 2015 09:40:21 -0400 Received: from chene.dit.umontreal.ca ([132.204.246.20]:52227) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlHMP-0004VK-QO for 20404@debbugs.gnu.org; Thu, 23 Apr 2015 09:40:11 -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 t3NDe80k024176; Thu, 23 Apr 2015 09:40:08 -0400 Received: by pastel.home (Postfix, from userid 20848) id 1746E1ED2; Thu, 23 Apr 2015 09:40:08 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time Message-ID: References: <87a8y0iji1.fsf@gnu.org> <20150422163110.68601.qmail@mail.muc.de> <87383rhqky.fsf@gnu.org> <83egnb3l2f.fsf@gnu.org> <877ft3cwf6.fsf@gnu.org> <83618n2vxu.fsf@gnu.org> Date: Thu, 23 Apr 2015 09:40:08 -0400 In-Reply-To: <83618n2vxu.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 23 Apr 2015 09:35:57 +0300") 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 RV5285=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5285> : inlines <2785> : streams <1427275> : uri <1913874> X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 20404 Cc: acm@muc.de, 20404@debbugs.gnu.org, Tassilo Horn 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 think I explained this back when there was a very long discussion of > Alan's fast-but-imprecise-scrolling patch. What was it? That input-pending-p returns nil even though there are lots of pending events (because they haven't been processed enough for Emacs to realize they're there)? Could you make a bug report about this issue, describing under which circumstances this happens? Or do we have one already? Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 23 09:40:23 2015 Received: (at 20404) by debbugs.gnu.org; 23 Apr 2015 13:40:23 +0000 Received: from localhost ([127.0.0.1]:37238 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlHMc-0004Vl-Bx for submit@debbugs.gnu.org; Thu, 23 Apr 2015 09:40:22 -0400 Received: from chene.dit.umontreal.ca ([132.204.246.20]:52226) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlHMP-0004VJ-Qi for 20404@debbugs.gnu.org; Thu, 23 Apr 2015 09:40:11 -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 t3NDe7uG024162; Thu, 23 Apr 2015 09:40:07 -0400 Received: by pastel.home (Postfix, from userid 20848) id D89B815C7; Thu, 23 Apr 2015 09:40:06 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time Message-ID: References: <87a8y0iji1.fsf@gnu.org> <83383r2sb3.fsf@gnu.org> <831tjb2q9z.fsf@gnu.org> Date: Thu, 23 Apr 2015 09:40:06 -0400 In-Reply-To: <831tjb2q9z.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 23 Apr 2015 11:38:16 +0300") 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 RV5285=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5285> : inlines <2785> : streams <1427275> : uri <1913874> X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 20404 Cc: 20404@debbugs.gnu.org, tsdh@gnu.org 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 (-) > And here's why: [...] > (when suggest-key-bindings > (sit-for (cond Oh, right. Another one of those "sit-for considered harmful". I think we need a new (run-after-if-still-idle TIME FUNCTION) which sets up a timer to run FUNCTION after TIME seconds, but where that timer is canceled as soon as "something happens" (I guess we could start by canceling that timer from pre-command-hook and hope it's sufficient). Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 23 11:11:36 2015 Received: (at 20404) by debbugs.gnu.org; 23 Apr 2015 15:11:37 +0000 Received: from localhost ([127.0.0.1]:37889 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlImu-0006kI-IT for submit@debbugs.gnu.org; Thu, 23 Apr 2015 11:11:36 -0400 Received: from mtaout29.012.net.il ([80.179.55.185]:41982) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlImr-0006k3-Q7 for 20404@debbugs.gnu.org; Thu, 23 Apr 2015 11:11:35 -0400 Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NN900700M09YI00@mtaout29.012.net.il> for 20404@debbugs.gnu.org; Thu, 23 Apr 2015 18:09:55 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NN9002DZM4JLI50@mtaout29.012.net.il>; Thu, 23 Apr 2015 18:09:55 +0300 (IDT) Date: Thu, 23 Apr 2015 18:11:28 +0300 From: Eli Zaretskii Subject: Re: bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <83h9s6282n.fsf@gnu.org> References: <87a8y0iji1.fsf@gnu.org> <20150422163110.68601.qmail@mail.muc.de> <87383rhqky.fsf@gnu.org> <83egnb3l2f.fsf@gnu.org> <877ft3cwf6.fsf@gnu.org> <83618n2vxu.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 20404 Cc: acm@muc.de, 20404@debbugs.gnu.org, tsdh@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii 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: Tassilo Horn , acm@muc.de, 20404@debbugs.gnu.org > Date: Thu, 23 Apr 2015 09:40:08 -0400 > > > I think I explained this back when there was a very long discussion of > > Alan's fast-but-imprecise-scrolling patch. > > What was it? That input-pending-p returns nil even though there are > lots of pending events (because they haven't been processed enough for > Emacs to realize they're there)? Could you make a bug report about this > issue, describing under which circumstances this happens? Or do we have > one already? Maybe we are not talking about the same thing. I meant these messages: http://lists.gnu.org/archive/html/emacs-devel/2014-10/msg00705.html http://lists.gnu.org/archive/html/emacs-devel/2014-10/msg01039.html http://lists.gnu.org/archive/html/emacs-devel/2014-10/msg01055.html I don't see the special case of zero discussed back there, so perhaps this is a different problem. From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 23 12:23:30 2015 Received: (at 20404) by debbugs.gnu.org; 23 Apr 2015 16:23:30 +0000 Received: from localhost ([127.0.0.1]:37951 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlJuT-0008So-Gu for submit@debbugs.gnu.org; Thu, 23 Apr 2015 12:23:29 -0400 Received: from mercure.iro.umontreal.ca ([132.204.24.67]:60811) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlJuR-0008Sg-R0 for 20404@debbugs.gnu.org; Thu, 23 Apr 2015 12:23:28 -0400 Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 9BD7385E8A; Thu, 23 Apr 2015 12:23:26 -0400 (EDT) Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 238A61E5B8C; Thu, 23 Apr 2015 12:23:03 -0400 (EDT) Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848) id EB256B40DC; Thu, 23 Apr 2015 12:23:02 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time Message-ID: References: <87a8y0iji1.fsf@gnu.org> <20150422163110.68601.qmail@mail.muc.de> <87383rhqky.fsf@gnu.org> <83egnb3l2f.fsf@gnu.org> <877ft3cwf6.fsf@gnu.org> <83618n2vxu.fsf@gnu.org> <83h9s6282n.fsf@gnu.org> Date: Thu, 23 Apr 2015 12:23:02 -0400 In-Reply-To: <83h9s6282n.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 23 Apr 2015 18:11:28 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82, MC_TSTLAST 0.00) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca X-Spam-Status: No X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 20404 Cc: acm@muc.de, 20404@debbugs.gnu.org, tsdh@gnu.org 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: -2.3 (--) >> What was it? That input-pending-p returns nil even though there are >> lots of pending events (because they haven't been processed enough for >> Emacs to realize they're there)? Could you make a bug report about this >> issue, describing under which circumstances this happens? Or do we have >> one already? > Maybe we are not talking about the same thing. I meant these > messages: > http://lists.gnu.org/archive/html/emacs-devel/2014-10/msg00705.html This message of yours seems to be talking about the problem I'm referring to above. At least, the way I read it, it seems to say that `input-pending-p' can return nil even if there is pending input (because that pending input is still in the system's input queue). If that's the case, we should have a bug report about that. > http://lists.gnu.org/archive/html/emacs-devel/2014-10/msg01039.html > http://lists.gnu.org/archive/html/emacs-devel/2014-10/msg01055.html These talk about something else, which is partly outdated. > I don't see the special case of zero discussed back there, so perhaps > this is a different problem. That's because the code has changed since. Now redisplay (which happens after running a command) is skipped based on the value of `input-pending-p' at the beginning of the *command*, rather than based on its value at the beginning of redisplay. And jit-lock.el has been changed to use (not (input-pending-p)), but only if jit-lock-defer-time is 0, so the special case for 0 is new. Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 23 13:03:57 2015 Received: (at 20404) by debbugs.gnu.org; 23 Apr 2015 17:03:57 +0000 Received: from localhost ([127.0.0.1]:37961 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlKXc-0000wU-9O for submit@debbugs.gnu.org; Thu, 23 Apr 2015 13:03:57 -0400 Received: from mtaout24.012.net.il ([80.179.55.180]:53314) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlKXZ-0000wE-2Y for 20404@debbugs.gnu.org; Thu, 23 Apr 2015 13:03:54 -0400 Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NN900C00QL0QW00@mtaout24.012.net.il> for 20404@debbugs.gnu.org; Thu, 23 Apr 2015 19:54:21 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NN9009A1QYLPE40@mtaout24.012.net.il>; Thu, 23 Apr 2015 19:54:21 +0300 (IDT) Date: Thu, 23 Apr 2015 20:03:11 +0300 From: Eli Zaretskii Subject: Re: bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <834mo622wg.fsf@gnu.org> References: <87a8y0iji1.fsf@gnu.org> <20150422163110.68601.qmail@mail.muc.de> <87383rhqky.fsf@gnu.org> <83egnb3l2f.fsf@gnu.org> <877ft3cwf6.fsf@gnu.org> <83618n2vxu.fsf@gnu.org> <83h9s6282n.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 20404 Cc: acm@muc.de, 20404@debbugs.gnu.org, tsdh@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii 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: tsdh@gnu.org, acm@muc.de, 20404@debbugs.gnu.org > Date: Thu, 23 Apr 2015 12:23:02 -0400 > > >> What was it? That input-pending-p returns nil even though there are > >> lots of pending events (because they haven't been processed enough for > >> Emacs to realize they're there)? Could you make a bug report about this > >> issue, describing under which circumstances this happens? Or do we have > >> one already? > > Maybe we are not talking about the same thing. I meant these > > messages: > > http://lists.gnu.org/archive/html/emacs-devel/2014-10/msg00705.html > > This message of yours seems to be talking about the problem I'm > referring to above. At least, the way I read it, it seems to say that > `input-pending-p' can return nil even if there is pending input > (because that pending input is still in the system's input queue). > If that's the case, we should have a bug report about that. > > > http://lists.gnu.org/archive/html/emacs-devel/2014-10/msg01039.html > > http://lists.gnu.org/archive/html/emacs-devel/2014-10/msg01055.html > > These talk about something else, which is partly outdated. > > > I don't see the special case of zero discussed back there, so perhaps > > this is a different problem. > > That's because the code has changed since. Now redisplay (which happens > after running a command) is skipped based on the value of > `input-pending-p' at the beginning of the *command*, rather than based > on its value at the beginning of redisplay. And jit-lock.el has been > changed to use (not (input-pending-p)), but only if jit-lock-defer-time > is 0, so the special case for 0 is new. FWIW, when I set jit-lock-defer-time to zero and lean on the PageDown key, I see somewhat clunky scrolling with no fontifications, until I release the key. But fontification inside the scrolling code itself still happens, I think. From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 23 13:25:27 2015 Received: (at 20404) by debbugs.gnu.org; 23 Apr 2015 17:25:27 +0000 Received: from localhost ([127.0.0.1]:37971 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlKsQ-0001Qj-BS for submit@debbugs.gnu.org; Thu, 23 Apr 2015 13:25:26 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:41160) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlKsN-0001QV-ES for 20404@debbugs.gnu.org; Thu, 23 Apr 2015 13:25:24 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NN900K00SDQQO00@a-mtaout22.012.net.il> for 20404@debbugs.gnu.org; Thu, 23 Apr 2015 20:25:16 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NN900KKBSE4GW70@a-mtaout22.012.net.il>; Thu, 23 Apr 2015 20:25:16 +0300 (IDT) Date: Thu, 23 Apr 2015 20:25:18 +0300 From: Eli Zaretskii Subject: Re: bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <83383q21vl.fsf@gnu.org> References: <87a8y0iji1.fsf@gnu.org> <20150422163110.68601.qmail@mail.muc.de> <87383rhqky.fsf@gnu.org> <83egnb3l2f.fsf@gnu.org> <877ft3cwf6.fsf@gnu.org> <83618n2vxu.fsf@gnu.org> <83h9s6282n.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 20404 Cc: acm@muc.de, 20404@debbugs.gnu.org, tsdh@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii 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: tsdh@gnu.org, acm@muc.de, 20404@debbugs.gnu.org > Date: Thu, 23 Apr 2015 12:23:02 -0400 > > > http://lists.gnu.org/archive/html/emacs-devel/2014-10/msg00705.html > > This message of yours seems to be talking about the problem I'm > referring to above. At least, the way I read it, it seems to say that > `input-pending-p' can return nil even if there is pending input > (because that pending input is still in the system's input queue). I don't see how what you say can follow from what I wrote in that message. What I say there is that while we process keystrokes, we don't call read_socket_hook. This observation is based on the code of get_input_pending, which is the workhorse of input-pending-p: static bool get_input_pending (int flags) { /* First of all, have we already counted some input? */ input_pending = (!NILP (Vquit_flag) || readable_events (flags)); /* If input is being read as it arrives, and we have none, there is none. */ if (!input_pending && (!interrupt_input || interrupts_deferred)) { /* Try to read some input and see how much we get. */ gobble_input (); input_pending = (!NILP (Vquit_flag) || readable_events (flags)); } return input_pending; The call to read_socket_hook is in gobble_input, so if the first call to readable_events returns non-zero, as it happens when we have events waiting in our keyboard queue, we won't call read_socket_hook. But that doesn't mean input-pending-p will return nil when there's input unread by read_socket_hook, because once our keyboard queue gets emptied, readable_events will return zero, and then we _will_ call read_socket_hook to fill our queue, and then the second call to readable_events will return non-zero, and input-pending-p will return non-nil. From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 23 13:28:12 2015 Received: (at 20404) by debbugs.gnu.org; 23 Apr 2015 17:28:12 +0000 Received: from localhost ([127.0.0.1]:37975 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlKv6-0001Uj-H1 for submit@debbugs.gnu.org; Thu, 23 Apr 2015 13:28:12 -0400 Received: from mercure.iro.umontreal.ca ([132.204.24.67]:59219) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlKv4-0001Ub-Lv for 20404@debbugs.gnu.org; Thu, 23 Apr 2015 13:28:11 -0400 Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 99B1D84830; Thu, 23 Apr 2015 13:27:53 -0400 (EDT) Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 7B4ED1E5B8D; Thu, 23 Apr 2015 13:27:20 -0400 (EDT) Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848) id 60944B40DC; Thu, 23 Apr 2015 13:27:20 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time Message-ID: References: <87a8y0iji1.fsf@gnu.org> <20150422163110.68601.qmail@mail.muc.de> <87383rhqky.fsf@gnu.org> <83egnb3l2f.fsf@gnu.org> <877ft3cwf6.fsf@gnu.org> <83618n2vxu.fsf@gnu.org> <83h9s6282n.fsf@gnu.org> <834mo622wg.fsf@gnu.org> Date: Thu, 23 Apr 2015 13:27:20 -0400 In-Reply-To: <834mo622wg.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 23 Apr 2015 20:03:11 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82, MC_TSTLAST 0.00) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca X-Spam-Status: No X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 20404 Cc: acm@muc.de, 20404@debbugs.gnu.org, tsdh@gnu.org 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: -2.3 (--) > FWIW, when I set jit-lock-defer-time to zero and lean on the PageDown > key, I see somewhat clunky scrolling with no fontifications, until I > release the key. > But fontification inside the scrolling code itself still happens, I > think. Hmm... while I guess it's still possible, it normally shouldn't happen: if the fontification takes place during the scrolling itself, then the next redisplay should not be skipped (and hence you should see fontified text rather than unfontified text, tho, some of the displayed text may still be unfontified, because it was marked as "fontified=defer" in the previous redisplay). So, if the text scrolls by fully unfontified, it should be the case that fontification did not happen during scrolling. Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 23 13:34:54 2015 Received: (at 20404) by debbugs.gnu.org; 23 Apr 2015 17:34:54 +0000 Received: from localhost ([127.0.0.1]:37984 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlL1Z-0001fq-UJ for submit@debbugs.gnu.org; Thu, 23 Apr 2015 13:34:54 -0400 Received: from mtaout29.012.net.il ([80.179.55.185]:48866) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlL1W-0001fc-RM for 20404@debbugs.gnu.org; Thu, 23 Apr 2015 13:34:51 -0400 Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NN900E00SMEEK00@mtaout29.012.net.il> for 20404@debbugs.gnu.org; Thu, 23 Apr 2015 20:33:11 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NN900DV7SRBYO00@mtaout29.012.net.il>; Thu, 23 Apr 2015 20:33:11 +0300 (IDT) Date: Thu, 23 Apr 2015 20:34:44 +0300 From: Eli Zaretskii Subject: Re: bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <83y4lizr2j.fsf@gnu.org> References: <87a8y0iji1.fsf@gnu.org> <20150422163110.68601.qmail@mail.muc.de> <87383rhqky.fsf@gnu.org> <83egnb3l2f.fsf@gnu.org> <877ft3cwf6.fsf@gnu.org> <83618n2vxu.fsf@gnu.org> <83h9s6282n.fsf@gnu.org> <834mo622wg.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 20404 Cc: acm@muc.de, 20404@debbugs.gnu.org, tsdh@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii 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: tsdh@gnu.org, acm@muc.de, 20404@debbugs.gnu.org > Date: Thu, 23 Apr 2015 13:27:20 -0400 > > > FWIW, when I set jit-lock-defer-time to zero and lean on the PageDown > > key, I see somewhat clunky scrolling with no fontifications, until I > > release the key. > > But fontification inside the scrolling code itself still happens, I > > think. > > Hmm... while I guess it's still possible, it normally shouldn't happen: > if the fontification takes place during the scrolling itself, then the > next redisplay should not be skipped How does this work? By "fontification inside scrolling" I mean fontification triggered by calling move_it_* functions, which simulate display. They will only fontify those parts of text over which they iterate, which might be much less than the window. > (and hence you should see fontified text rather than unfontified > text, tho, some of the displayed text may still be unfontified, > because it was marked as "fontified=defer" in the previous > redisplay). It's hard to say, but I'm almost sure I sometimes indeed see a small part of the scrolling window, near its beginning, fontified. Or maybe I'm just imagining things. From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 23 15:32:47 2015 Received: (at 20404) by debbugs.gnu.org; 23 Apr 2015 19:32:47 +0000 Received: from localhost ([127.0.0.1]:38021 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlMre-0004Nk-Uj for submit@debbugs.gnu.org; Thu, 23 Apr 2015 15:32:47 -0400 Received: from mercure.iro.umontreal.ca ([132.204.24.67]:59591) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlMrb-0004NZ-7m for 20404@debbugs.gnu.org; Thu, 23 Apr 2015 15:32:43 -0400 Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 460F285EE6; Thu, 23 Apr 2015 15:32:40 -0400 (EDT) Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id A57881E5B96; Thu, 23 Apr 2015 15:31:56 -0400 (EDT) Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848) id 72A48B40DC; Thu, 23 Apr 2015 15:31:56 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time Message-ID: References: <87a8y0iji1.fsf@gnu.org> <20150422163110.68601.qmail@mail.muc.de> <87383rhqky.fsf@gnu.org> <83egnb3l2f.fsf@gnu.org> <877ft3cwf6.fsf@gnu.org> <83618n2vxu.fsf@gnu.org> <83h9s6282n.fsf@gnu.org> <83383q21vl.fsf@gnu.org> Date: Thu, 23 Apr 2015 15:31:56 -0400 In-Reply-To: <83383q21vl.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 23 Apr 2015 20:25:18 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82, MC_TSTLAST 0.00) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca X-Spam-Status: No X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 20404 Cc: acm@muc.de, 20404@debbugs.gnu.org, tsdh@gnu.org 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: -2.3 (--) > I don't see how what you say can follow from what I wrote in that message. I just misunderstood. > But that doesn't mean input-pending-p will return nil when there's > input unread by read_socket_hook, because once our keyboard queue gets > emptied, readable_events will return zero, and then we _will_ call > read_socket_hook to fill our queue, and then the second call to > readable_events will return non-zero, and input-pending-p will return > non-nil. Good. But then I don't understand why Tassilo gets the same display freezes with jit-lock-defer-time set to 0 as when jit-lock-defer-time is set to nil. You seem to say that you know why (and that you explained it in those old discussions), but I guess I don't understand those explanations. Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 23 15:35:45 2015 Received: (at 20404) by debbugs.gnu.org; 23 Apr 2015 19:35:45 +0000 Received: from localhost ([127.0.0.1]:38025 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlMuW-0004Rt-Ml for submit@debbugs.gnu.org; Thu, 23 Apr 2015 15:35:45 -0400 Received: from mercure.iro.umontreal.ca ([132.204.24.67]:37074) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlMuU-0004Rj-Kq for 20404@debbugs.gnu.org; Thu, 23 Apr 2015 15:35:42 -0400 Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 1358885EE6; Thu, 23 Apr 2015 15:35:42 -0400 (EDT) Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 3F4D61E5B8D; Thu, 23 Apr 2015 15:35:18 -0400 (EDT) Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848) id 1E5CEB40DC; Thu, 23 Apr 2015 15:35:18 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time Message-ID: References: <87a8y0iji1.fsf@gnu.org> <20150422163110.68601.qmail@mail.muc.de> <87383rhqky.fsf@gnu.org> <83egnb3l2f.fsf@gnu.org> <877ft3cwf6.fsf@gnu.org> <83618n2vxu.fsf@gnu.org> <83h9s6282n.fsf@gnu.org> <834mo622wg.fsf@gnu.org> <83y4lizr2j.fsf@gnu.org> Date: Thu, 23 Apr 2015 15:35:18 -0400 In-Reply-To: <83y4lizr2j.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 23 Apr 2015 20:34:44 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82, MC_TSTLAST 0.00) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca X-Spam-Status: No X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 20404 Cc: acm@muc.de, 20404@debbugs.gnu.org, tsdh@gnu.org 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: -2.3 (--) >> Hmm... while I guess it's still possible, it normally shouldn't happen: >> if the fontification takes place during the scrolling itself, then the >> next redisplay should not be skipped > How does this work? The decision whether redisplay is skipped or not is based on the input-pending-p at the beginning of the command, i.e. before the call to move_it. So, if move_it triggers jit-lock which triggers font-lock, that means jit-lock found (during move_it) that input-pending-p was nil, which should imply that input-pending-p was also nil at the beginning of the command, and hence the next redisplay will not be skipped. > It's hard to say, but I'm almost sure I sometimes indeed see a small > part of the scrolling window, near its beginning, fontified. Or maybe > I'm just imagining things. Then I guess it's within the "explainable behavior". Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 23 15:52:16 2015 Received: (at 20404) by debbugs.gnu.org; 23 Apr 2015 19:52:17 +0000 Received: from localhost ([127.0.0.1]:38043 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlNAW-0004pI-CJ for submit@debbugs.gnu.org; Thu, 23 Apr 2015 15:52:16 -0400 Received: from mtaout26.012.net.il ([80.179.55.182]:36320) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlNAT-0004p3-Tr for 20404@debbugs.gnu.org; Thu, 23 Apr 2015 15:52:15 -0400 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NN900D00Z8RS900@mtaout26.012.net.il> for 20404@debbugs.gnu.org; Thu, 23 Apr 2015 22:53:41 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NN900AIJZ9H5O30@mtaout26.012.net.il>; Thu, 23 Apr 2015 22:53:41 +0300 (IDT) Date: Thu, 23 Apr 2015 22:52:08 +0300 From: Eli Zaretskii Subject: Re: bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <83sibqzkpj.fsf@gnu.org> References: <87a8y0iji1.fsf@gnu.org> <20150422163110.68601.qmail@mail.muc.de> <87383rhqky.fsf@gnu.org> <83egnb3l2f.fsf@gnu.org> <877ft3cwf6.fsf@gnu.org> <83618n2vxu.fsf@gnu.org> <83h9s6282n.fsf@gnu.org> <83383q21vl.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 20404 Cc: acm@muc.de, 20404@debbugs.gnu.org, tsdh@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii 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: tsdh@gnu.org, acm@muc.de, 20404@debbugs.gnu.org > Date: Thu, 23 Apr 2015 15:31:56 -0400 > > > I don't see how what you say can follow from what I wrote in that message. > > I just misunderstood. > > > But that doesn't mean input-pending-p will return nil when there's > > input unread by read_socket_hook, because once our keyboard queue gets > > emptied, readable_events will return zero, and then we _will_ call > > read_socket_hook to fill our queue, and then the second call to > > readable_events will return non-zero, and input-pending-p will return > > non-nil. > > Good. But then I don't understand why Tassilo gets the same display > freezes with jit-lock-defer-time set to 0 as when jit-lock-defer-time is > set to nil. Neither do I. I see a very big difference: with jit-lock-defer-time set to zero, the freezes are minor and almost non-existent. With it set to nil, they are much more evident and much longer. > You seem to say that you know why (and that you explained it in those > old discussions), but I guess I don't understand those explanations. I never said the value of zero should have no effect, nor do I thing it should, or does. From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 23 15:53:52 2015 Received: (at 20404) by debbugs.gnu.org; 23 Apr 2015 19:53:52 +0000 Received: from localhost ([127.0.0.1]:38047 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlNC4-0004rR-4g for submit@debbugs.gnu.org; Thu, 23 Apr 2015 15:53:52 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:39362) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlNC1-0004rI-5F for 20404@debbugs.gnu.org; Thu, 23 Apr 2015 15:53:49 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id E363820AA8 for <20404@debbugs.gnu.org>; Thu, 23 Apr 2015 15:53:48 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Thu, 23 Apr 2015 15:53: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=RTY2e+GesNcS5hGIHaOqzpa7/Es=; b=XsswV 5l3+rb9EgqlGdFB4CFl1DW5UF5R3p5vlQ4pLVHESLXBT/itRNN/iiGWSBxeTrg2G WnfrWzhCzftU0yV+avMascuIHjZp1N4Nvd4v/0tlhXIUYp1met1LK5cBNXHIhJ6G +BN5SYLCidEs8ksgc4KfRcKuOYSafALNposGhk= X-Sasl-enc: gVD24Tv/poqPotLaZQ9sS0861PBbk40/GDunQeOzTGKR 1429818828 Received: from thinkpad-t440p (unknown [2.162.110.201]) by mail.messagingengine.com (Postfix) with ESMTPA id 8D78DC00011; Thu, 23 Apr 2015 15:53:47 -0400 (EDT) From: Tassilo Horn To: Eli Zaretskii Subject: Re: bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time References: <87a8y0iji1.fsf@gnu.org> <20150422163110.68601.qmail@mail.muc.de> <87383rhqky.fsf@gnu.org> <83egnb3l2f.fsf@gnu.org> <877ft3cwf6.fsf@gnu.org> <83618n2vxu.fsf@gnu.org> <83h9s6282n.fsf@gnu.org> <834mo622wg.fsf@gnu.org> Date: Thu, 23 Apr 2015 21:53:44 +0200 In-Reply-To: <834mo622wg.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 23 Apr 2015 20:03:11 +0300") Message-ID: <87pp6uoc3b.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-Debbugs-Envelope-To: 20404 Cc: acm@muc.de, Stefan Monnier , 20404@debbugs.gnu.org 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: >> That's because the code has changed since. Now redisplay (which >> happens after running a command) is skipped based on the value of >> `input-pending-p' at the beginning of the *command*, rather than >> based on its value at the beginning of redisplay. And jit-lock.el >> has been changed to use (not (input-pending-p)), but only if >> jit-lock-defer-time is 0, so the special case for 0 is new. > > FWIW, when I set jit-lock-defer-time to zero and lean on the PageDown > key, I see somewhat clunky scrolling with no fontifications, until I > release the key. Oh, I've told you that I get the display freezes even with jit-lock-defer-time set to zero but I've been wrong. My error was that I called `emacs -Q src/buffer.c', then set jit-lock-defer-time to zero in *scratch*, and then scrolled in buffer.c. But the effect applies only to new buffers. So with jit-lock-defer-time = 0, scrolling doesn't freeze the display, and also the "no fontification problem" in bug report buffers or byte-compilation output buffers doesn't occur anymore. > But fontification inside the scrolling code itself still happens, I > think. Yes, most text that scrolls by is black on white but occassionally I can catch sight of something reddish (a string or comment) or bluish (function name). Bye, Tassilo From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 23 15:56:47 2015 Received: (at 20404) by debbugs.gnu.org; 23 Apr 2015 19:56:47 +0000 Received: from localhost ([127.0.0.1]:38055 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlNEs-0004vo-L0 for submit@debbugs.gnu.org; Thu, 23 Apr 2015 15:56:46 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:43079) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlNEq-0004vg-N8 for 20404@debbugs.gnu.org; Thu, 23 Apr 2015 15:56:45 -0400 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 7E725207A8 for <20404@debbugs.gnu.org>; Thu, 23 Apr 2015 15:56:44 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Thu, 23 Apr 2015 15:56:44 -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=91jLTAw4q9TUIGF4apKj6BtyNVM=; b=a88YS fq6/JVJByXIgWw58ssjdbKcvOrwsI9O80u2czpn8yNLB0+jHgMIt5+gLM1hxeaRx yrRMwnLxwSu/la51T/IWojEVSeUy8jlRYFiiLH7gCUJF/+F7+WE4k0T9Ta/GQ/cx vKg+6lwqabUpoAcC6mhsGQPZT1Y3Cjaddiofc4= X-Sasl-enc: q+do3mOhkowBPTRLb5fncUQoXSUB1r6+80Z23RI3r6mp 1429819003 Received: from thinkpad-t440p (unknown [2.162.110.201]) by mail.messagingengine.com (Postfix) with ESMTPA id F0BE168010F; Thu, 23 Apr 2015 15:56:42 -0400 (EDT) From: Tassilo Horn To: Stefan Monnier Subject: Re: bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time References: <87a8y0iji1.fsf@gnu.org> <20150422163110.68601.qmail@mail.muc.de> <87383rhqky.fsf@gnu.org> <83egnb3l2f.fsf@gnu.org> <877ft3cwf6.fsf@gnu.org> <83618n2vxu.fsf@gnu.org> <83h9s6282n.fsf@gnu.org> <83383q21vl.fsf@gnu.org> Date: Thu, 23 Apr 2015 21:56:40 +0200 In-Reply-To: (Stefan Monnier's message of "Thu, 23 Apr 2015 15:31:56 -0400") Message-ID: <87lhhiobyf.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-Debbugs-Envelope-To: 20404 Cc: acm@muc.de, Eli Zaretskii , 20404@debbugs.gnu.org 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: >> But that doesn't mean input-pending-p will return nil when there's >> input unread by read_socket_hook, because once our keyboard queue >> gets emptied, readable_events will return zero, and then we _will_ >> call read_socket_hook to fill our queue, and then the second call to >> readable_events will return non-zero, and input-pending-p will return >> non-nil. > > Good. But then I don't understand why Tassilo gets the same display > freezes with jit-lock-defer-time set to 0 as when jit-lock-defer-time is > set to nil. Sorry, sorry, sorry. I've been wrong. I had opened the test buffer.c buffer already before I've set jit-lock-defer-time to zero, and then the new value had no effect on that buffer. Now I can confirm that j-l-d-t = 0 fixes both the display freezes and the non-fontified bug report or byte-compile buffers. Bye, Tassilo From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 24 05:41:31 2015 Received: (at 20404) by debbugs.gnu.org; 24 Apr 2015 09:41:31 +0000 Received: from localhost ([127.0.0.1]:38340 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yla70-0000aC-JM for submit@debbugs.gnu.org; Fri, 24 Apr 2015 05:41:30 -0400 Received: from mtaout27.012.net.il ([80.179.55.183]:42964) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yla6x-0000Zx-S9 for 20404@debbugs.gnu.org; Fri, 24 Apr 2015 05:41:29 -0400 Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NNB00K00129R700@mtaout27.012.net.il> for 20404@debbugs.gnu.org; Fri, 24 Apr 2015 12:36:23 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNB00EGJ1CNRZ70@mtaout27.012.net.il>; Fri, 24 Apr 2015 12:36:23 +0300 (IDT) Date: Fri, 24 Apr 2015 12:41:16 +0300 From: Eli Zaretskii Subject: Re: bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <83618lzww3.fsf@gnu.org> References: <87a8y0iji1.fsf@gnu.org> <20150422163110.68601.qmail@mail.muc.de> <87383rhqky.fsf@gnu.org> <83egnb3l2f.fsf@gnu.org> <877ft3cwf6.fsf@gnu.org> <83618n2vxu.fsf@gnu.org> <83h9s6282n.fsf@gnu.org> <834mo622wg.fsf@gnu.org> <83y4lizr2j.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 20404 Cc: acm@muc.de, 20404@debbugs.gnu.org, tsdh@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii 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: tsdh@gnu.org, acm@muc.de, 20404@debbugs.gnu.org > Date: Thu, 23 Apr 2015 15:35:18 -0400 > > >> Hmm... while I guess it's still possible, it normally shouldn't happen: > >> if the fontification takes place during the scrolling itself, then the > >> next redisplay should not be skipped > > How does this work? > > The decision whether redisplay is skipped or not is based on the > input-pending-p at the beginning of the command, i.e. before the call to > move_it. > So, if move_it triggers jit-lock which triggers font-lock, that means > jit-lock found (during move_it) that input-pending-p was nil, which > should imply that input-pending-p was also nil at the beginning of the > command, and hence the next redisplay will not be skipped. I'm not sure I see all this; perhaps I'm looking at the wrong places. What I see is that the only reference to input-pending-p in jit-lock.el is in jit-lock-function, where it is used to decide whether to defer fontifications, which I believe is not what you were describing above. So how does "jit-lock find (during move_it) that input-pending-p is nil"? From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 24 10:03:51 2015 Received: (at 20404) by debbugs.gnu.org; 24 Apr 2015 14:03:51 +0000 Received: from localhost ([127.0.0.1]:38820 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YleCo-00006L-3T for submit@debbugs.gnu.org; Fri, 24 Apr 2015 10:03:50 -0400 Received: from chene.dit.umontreal.ca ([132.204.246.20]:57576) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YleCi-000067-Nz for 20404@debbugs.gnu.org; Fri, 24 Apr 2015 10:03:45 -0400 Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t3OE3dgU028808; Fri, 24 Apr 2015 10:03:39 -0400 Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 9839FAE113; Fri, 24 Apr 2015 10:03:39 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time Message-ID: References: <87a8y0iji1.fsf@gnu.org> <20150422163110.68601.qmail@mail.muc.de> <87383rhqky.fsf@gnu.org> <83egnb3l2f.fsf@gnu.org> <877ft3cwf6.fsf@gnu.org> <83618n2vxu.fsf@gnu.org> <83h9s6282n.fsf@gnu.org> <834mo622wg.fsf@gnu.org> <83y4lizr2j.fsf@gnu.org> <83618lzww3.fsf@gnu.org> Date: Fri, 24 Apr 2015 10:03:39 -0400 In-Reply-To: <83618lzww3.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 24 Apr 2015 12:41:16 +0300") 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, RV5286=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5286> : inlines <2791> : streams <1427833> : uri <1914722> X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 20404 Cc: acm@muc.de, 20404@debbugs.gnu.org, tsdh@gnu.org 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 (-) > So how does "jit-lock find (during move_it) that input-pending-p is nil"? With the input-pending-p in jit-lock-function. Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 24 10:37:08 2015 Received: (at 20404) by debbugs.gnu.org; 24 Apr 2015 14:37:08 +0000 Received: from localhost ([127.0.0.1]:38841 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Ylej3-0000su-23 for submit@debbugs.gnu.org; Fri, 24 Apr 2015 10:37:08 -0400 Received: from mtaout24.012.net.il ([80.179.55.180]:50227) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yleiy-0000sM-0z for 20404@debbugs.gnu.org; Fri, 24 Apr 2015 10:37:03 -0400 Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NNB00J00EIE0700@mtaout24.012.net.il> for 20404@debbugs.gnu.org; Fri, 24 Apr 2015 17:28:05 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NNB00K48EUTL900@mtaout24.012.net.il>; Fri, 24 Apr 2015 17:28:05 +0300 (IDT) Date: Fri, 24 Apr 2015 17:36:44 +0300 From: Eli Zaretskii Subject: Re: bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <834mo5zj7n.fsf@gnu.org> References: <87a8y0iji1.fsf@gnu.org> <20150422163110.68601.qmail@mail.muc.de> <87383rhqky.fsf@gnu.org> <83egnb3l2f.fsf@gnu.org> <877ft3cwf6.fsf@gnu.org> <83618n2vxu.fsf@gnu.org> <83h9s6282n.fsf@gnu.org> <834mo622wg.fsf@gnu.org> <83y4lizr2j.fsf@gnu.org> <83618lzww3.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 20404 Cc: acm@muc.de, 20404@debbugs.gnu.org, tsdh@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii 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: tsdh@gnu.org, acm@muc.de, 20404@debbugs.gnu.org > Date: Fri, 24 Apr 2015 10:03:39 -0400 > > > So how does "jit-lock find (during move_it) that input-pending-p is nil"? > > With the input-pending-p in jit-lock-function. So you were describing something that happens only when jit-lock-defer-time is zero, not the general behavior. Nice misunderstanding. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 24 14:03:04 2015 Received: (at 20404) by debbugs.gnu.org; 24 Apr 2015 18:03:04 +0000 Received: from localhost ([127.0.0.1]:38910 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlhwN-0006DR-PY for submit@debbugs.gnu.org; Fri, 24 Apr 2015 14:03:04 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:37647) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlhwL-0006D2-OM for 20404@debbugs.gnu.org; Fri, 24 Apr 2015 14:03:02 -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 t3OI2wtV003200; Fri, 24 Apr 2015 14:02:58 -0400 Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 74CD1AE113; Fri, 24 Apr 2015 14:03:00 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time Message-ID: References: <87a8y0iji1.fsf@gnu.org> <20150422163110.68601.qmail@mail.muc.de> <87383rhqky.fsf@gnu.org> <83egnb3l2f.fsf@gnu.org> <877ft3cwf6.fsf@gnu.org> <83618n2vxu.fsf@gnu.org> <83h9s6282n.fsf@gnu.org> <834mo622wg.fsf@gnu.org> <83y4lizr2j.fsf@gnu.org> <83618lzww3.fsf@gnu.org> <834mo5zj7n.fsf@gnu.org> Date: Fri, 24 Apr 2015 14:03:00 -0400 In-Reply-To: <834mo5zj7n.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 24 Apr 2015 17:36:44 +0300") 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, RV5286=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5286> : inlines <2793> : streams <1427922> : uri <1914870> X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 20404 Cc: acm@muc.de, 20404@debbugs.gnu.org, tsdh@gnu.org 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 (-) > So you were describing something that happens only when > jit-lock-defer-time is zero, not the general behavior. That's right. Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 31 10:23:25 2019 Received: (at 20404) by debbugs.gnu.org; 31 Oct 2019 14:23:25 +0000 Received: from localhost ([127.0.0.1]:53943 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iQBMC-0005Sb-Mz for submit@debbugs.gnu.org; Thu, 31 Oct 2019 10:23:24 -0400 Received: from quimby.gnus.org ([80.91.231.51]:46146) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iQBM8-0005SP-Mf for 20404@debbugs.gnu.org; Thu, 31 Oct 2019 10:23:23 -0400 Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iQBM4-0001MO-S5; Thu, 31 Oct 2019 15:23:19 +0100 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time References: <87a8y0iji1.fsf@gnu.org> <83383r2sb3.fsf@gnu.org> <831tjb2q9z.fsf@gnu.org> Date: Thu, 31 Oct 2019 15:23:16 +0100 In-Reply-To: <831tjb2q9z.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 23 Apr 2015 11:38:16 +0300") Message-ID: <87pnid6lkb.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.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: Eli Zaretskii writes: > emacs -Q > M-x blink-cursor-mode RET > M-x blink-cursor-mode RET > > And note that after the second "M-x blink-cursor-mode RET", which > turns ON the blinking, Emacs waits for about the same 2 sec b [...] 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: 0.0 (/) X-Debbugs-Envelope-To: 20404 Cc: 20404@debbugs.gnu.org, tsdh@gnu.org 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: -1.0 (-) Eli Zaretskii writes: > emacs -Q > M-x blink-cursor-mode RET > M-x blink-cursor-mode RET > > And note that after the second "M-x blink-cursor-mode RET", which > turns ON the blinking, Emacs waits for about the same 2 sec before it > actually starts blinking. > > And here's why: _any_ command that goes through > execute-extended-command will run this code: > > (when suggest-key-bindings > (sit-for (cond > ((zerop (length (current-message))) 0) > ((numberp suggest-key-bindings) suggest-key-bindings) > (t 2)))))) This was fixed in 2018 by this commit, I think. commit 48a28f8e389c33029ab4aa3d65445f42ed457e11 Author: Dmitry Gutov Date: Mon Dec 24 04:36:08 2018 +0200 execute-extended-command: Skip waiting in more cases * lisp/simple.el (execute-extended-command): Don't wait when there's no binding the current command, and the user doesn't want to see "shorter" suggestions, or TYPED is nil anyway. Skimming this thread, it's unclear whether there was anything else to fix here. Can this bug be closed? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 31 10:23:29 2019 Received: (at control) by debbugs.gnu.org; 31 Oct 2019 14:23:30 +0000 Received: from localhost ([127.0.0.1]:53946 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iQBMH-0005Sr-3X for submit@debbugs.gnu.org; Thu, 31 Oct 2019 10:23:29 -0400 Received: from quimby.gnus.org ([80.91.231.51]:46160) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iQBMC-0005Sa-Sm for control@debbugs.gnu.org; Thu, 31 Oct 2019 10:23:25 -0400 Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iQBMA-0001MW-61 for control@debbugs.gnu.org; Thu, 31 Oct 2019 15:23:24 +0100 Date: Thu, 31 Oct 2019 15:23:21 +0100 Message-Id: <87o8xx6lk6.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #20404 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 20404 + 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: 0.0 (/) 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: -1.0 (-) tags 20404 + moreinfo quit From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 31 10:52:01 2019 Received: (at 20404-done) by debbugs.gnu.org; 31 Oct 2019 14:52:01 +0000 Received: from localhost ([127.0.0.1]:54029 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iQBnt-0008CN-2H for submit@debbugs.gnu.org; Thu, 31 Oct 2019 10:52:01 -0400 Received: from eggs.gnu.org ([209.51.188.92]:42896) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iQBnq-0008C8-Jz for 20404-done@debbugs.gnu.org; Thu, 31 Oct 2019 10:51:59 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:54660) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iQBnl-0006kB-Ax; Thu, 31 Oct 2019 10:51:53 -0400 Received: from [176.228.60.248] (port=3335 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iQBnj-000067-VA; Thu, 31 Oct 2019 10:51:52 -0400 Date: Thu, 31 Oct 2019 16:51:52 +0200 Message-Id: <83a79hnf1z.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-reply-to: <87pnid6lkb.fsf@gnus.org> (message from Lars Ingebrigtsen on Thu, 31 Oct 2019 15:23:16 +0100) Subject: Re: bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time References: <87a8y0iji1.fsf@gnu.org> <83383r2sb3.fsf@gnu.org> <831tjb2q9z.fsf@gnu.org> <87pnid6lkb.fsf@gnus.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 20404-done Cc: 20404-done@debbugs.gnu.org, tsdh@gnu.org 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 (---) > From: Lars Ingebrigtsen > Cc: tsdh@gnu.org, 20404@debbugs.gnu.org > Date: Thu, 31 Oct 2019 15:23:16 +0100 > > > And here's why: _any_ command that goes through > > execute-extended-command will run this code: > > > > (when suggest-key-bindings > > (sit-for (cond > > ((zerop (length (current-message))) 0) > > ((numberp suggest-key-bindings) suggest-key-bindings) > > (t 2)))))) > > This was fixed in 2018 by this commit, I think. > > commit 48a28f8e389c33029ab4aa3d65445f42ed457e11 > Author: Dmitry Gutov > Date: Mon Dec 24 04:36:08 2018 +0200 > > execute-extended-command: Skip waiting in more cases > > * lisp/simple.el (execute-extended-command): Don't wait when > there's no binding the current command, and the user doesn't want > to see "shorter" suggestions, or TYPED is nil anyway. > > Skimming this thread, it's unclear whether there was anything else to > fix here. Can this bug be closed? Yes; done. Thanks. From unknown Fri Aug 22 01:33:49 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 29 Nov 2019 12:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator