From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tassilo Horn Newsgroups: gmane.emacs.bugs Subject: bug#21747: 25.0.50; while-no-input breaks kbd event handling when called from post-command-hook Date: Sat, 24 Oct 2015 10:53:12 +0200 Message-ID: <877fmcejgn.fsf@gnu.org> References: <87bnboemqb.fsf@gnu.org> <838u6sy9s1.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1445676863 13738 80.91.229.3 (24 Oct 2015 08:54:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 24 Oct 2015 08:54:23 +0000 (UTC) Cc: 21747@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Oct 24 10:54:11 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 1ZpuaY-0003ME-5p for geb-bug-gnu-emacs@m.gmane.org; Sat, 24 Oct 2015 10:54:10 +0200 Original-Received: from localhost ([::1]:43503 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZpuaX-00058l-8o for geb-bug-gnu-emacs@m.gmane.org; Sat, 24 Oct 2015 04:54:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49160) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZpuaT-00058V-Oc for bug-gnu-emacs@gnu.org; Sat, 24 Oct 2015 04:54:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZpuaQ-0004ZC-HI for bug-gnu-emacs@gnu.org; Sat, 24 Oct 2015 04:54:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:44810) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZpuaQ-0004Z8-EV for bug-gnu-emacs@gnu.org; Sat, 24 Oct 2015 04:54:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZpuaQ-0007ZI-6q for bug-gnu-emacs@gnu.org; Sat, 24 Oct 2015 04:54:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Tassilo Horn Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 24 Oct 2015 08:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21747 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21747-submit@debbugs.gnu.org id=B21747.144567679629035 (code B ref 21747); Sat, 24 Oct 2015 08:54:02 +0000 Original-Received: (at 21747) by debbugs.gnu.org; 24 Oct 2015 08:53:16 +0000 Original-Received: from localhost ([127.0.0.1]:35518 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZpuZf-0007YF-VX for submit@debbugs.gnu.org; Sat, 24 Oct 2015 04:53:16 -0400 Original-Received: from nsmtp.uni-koblenz.de ([141.26.64.14]:42698) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZpuZd-0007Y6-KN for 21747@debbugs.gnu.org; Sat, 24 Oct 2015 04:53:14 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by nsmtp.uni-koblenz.de (Postfix) with ESMTP id BD6AE23B2BC; Sat, 24 Oct 2015 10:53:12 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at uni-koblenz.de Original-Received: from nsmtp.uni-koblenz.de ([127.0.0.1]) by localhost (nsmtp.uni-koblenz.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlnVfzPdNVdH; Sat, 24 Oct 2015 10:53:12 +0200 (CEST) Original-Received: from deliver.uni-koblenz.de (deliver.uni-koblenz.de [141.26.64.15]) by nsmtp.uni-koblenz.de (Postfix) with ESMTPS; Sat, 24 Oct 2015 10:53:12 +0200 (CEST) Original-Received: from thinkpad-t440p (dhcp66.uni-koblenz.de [141.26.71.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by deliver.uni-koblenz.de (Postfix) with ESMTPSA id 7A1821A8308; Sat, 24 Oct 2015 10:53:12 +0200 (CEST) In-Reply-To: <838u6sy9s1.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 24 Oct 2015 11:02:06 +0300") User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) 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: 208.118.235.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:107972 Archived-At: Eli Zaretskii writes: >> With emacs -Q, evaluate the following in *stratch*: >> >> --8<---------------cut here---------------start------------->8--- >> (defun th/loop-on-no-input () >> (while-no-input (while t t))) >> >> (add-hook 'post-command-hook #'th/loop-on-no-input) >> --8<---------------cut here---------------end--------------->8--- >> >> After having done that, the effect of pressing any key is deferred >> until you press the next key. E.g., typing "foo" just inserts "fo", >> but after an additional C-b (the exact key doesn't matter) you'll see >> "foo". > > I think what's deferred is redisplay, not the effect of pressing a > key. IOW, the key does its thing, the character is inserted into the > current buffer, but redisplay doesn't run, and so you don't see that > inserted character, and think it was not inserted in the first place. Yes, you are right. > Given that, maybe I'm missing something, but what did you expect? The > above literally says that Emacs shall loop indefinitely after > performing each command until there's more input. And that's what you > get. Right? Correct, but when the input eventually arrives, I expect to see its effects as if it had arrived outside of the `while-no-input'. > If I change the hook function to this: > > (defun th/loop-on-no-input () > (while-no-input (while t (sit-for 0)))) > > then the "delay" goes away Indeed, that works. > (although I still don't recommend such virulent post-command hooks, as > they make an otherwise idle Emacs suck all the juice out of a single > execution unit). > > Am I missing something here? Obviously, `aggressive-indent-mode's `post-command-hook' is no infinite loop but just a reasonably costly operation which should have the ability to be aborted when the user keeps on typing: https://github.com/Malabarba/aggressive-indent-mode/blob/master/aggressive-indent.el#L357 So the question is: should `while-no-input' call (sit-for 0) as the first statement in the `progn' or should functions using `while-no-input' do that on their own? I'd prefer the former because the current behavior is not really obvious (at least not to me nor Artur). Bye, Tassilo