From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#20404: 25.0.50; Sometimes no fontification with jit-lock-defer-time Date: Thu, 23 Apr 2015 12:16:51 +0300 Message-ID: <83zj5z19x8.fsf@gnu.org> References: <87a8y0iji1.fsf@gnu.org> <83383r2sb3.fsf@gnu.org> <831tjb2q9z.fsf@gnu.org> <87bnifw6z8.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1429780643 18930 80.91.229.3 (23 Apr 2015 09:17:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 23 Apr 2015 09:17:23 +0000 (UTC) Cc: 20404@debbugs.gnu.org To: Tassilo Horn Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Apr 23 11:17:12 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YlDFu-00034N-Uh for geb-bug-gnu-emacs@m.gmane.org; Thu, 23 Apr 2015 11:17:11 +0200 Original-Received: from localhost ([::1]:39048 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YlDFu-0001kk-3X for geb-bug-gnu-emacs@m.gmane.org; Thu, 23 Apr 2015 05:17:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55538) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YlDFp-0001kR-Mc for bug-gnu-emacs@gnu.org; Thu, 23 Apr 2015 05:17:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YlDFm-0002v3-F5 for bug-gnu-emacs@gnu.org; Thu, 23 Apr 2015 05:17:05 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:47362) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YlDFm-0002uz-Bj for bug-gnu-emacs@gnu.org; Thu, 23 Apr 2015 05:17:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YlDFl-0005Pa-RS for bug-gnu-emacs@gnu.org; Thu, 23 Apr 2015 05:17:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 23 Apr 2015 09:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20404 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 20404-submit@debbugs.gnu.org id=B20404.142978062020792 (code B ref 20404); Thu, 23 Apr 2015 09:17:01 +0000 Original-Received: (at 20404) by debbugs.gnu.org; 23 Apr 2015 09:17:00 +0000 Original-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 Original-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 Original-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) Original-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) In-reply-to: <87bnifw6z8.fsf@gnu.org> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:101916 Archived-At: > 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.