From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Michael Heerdegen Newsgroups: gmane.emacs.bugs Subject: bug#31692: Emacs sometimes drops key events Date: Thu, 07 Jun 2018 01:12:54 +0200 Message-ID: <87vaav8q6h.fsf@web.de> References: <83wovgd2aj.fsf@gnu.org> <87po163v65.fsf@web.de> <83in6yarhe.fsf@gnu.org> <877encq5co.fsf@web.de> <838t7sabds.fsf@gnu.org> <87muw8k4dk.fsf@web.de> <83zi08vufl.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1528326734 5914 195.159.176.226 (6 Jun 2018 23:12:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 6 Jun 2018 23:12:14 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: radon.neon@gmail.com, 31692@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jun 07 01:12:10 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fQhb4-0001Lm-I9 for geb-bug-gnu-emacs@m.gmane.org; Thu, 07 Jun 2018 01:12:06 +0200 Original-Received: from localhost ([::1]:55012 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fQhdA-0005tB-6S for geb-bug-gnu-emacs@m.gmane.org; Wed, 06 Jun 2018 19:14:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57813) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fQhd1-0005s1-7T for bug-gnu-emacs@gnu.org; Wed, 06 Jun 2018 19:14:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fQhcw-0008VK-6W for bug-gnu-emacs@gnu.org; Wed, 06 Jun 2018 19:14:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:57551) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fQhcw-0008VB-2k for bug-gnu-emacs@gnu.org; Wed, 06 Jun 2018 19:14:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fQhcv-0006Dz-QG for bug-gnu-emacs@gnu.org; Wed, 06 Jun 2018 19:14:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 06 Jun 2018 23:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 31692 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 31692-submit@debbugs.gnu.org id=B31692.152832678523851 (code B ref 31692); Wed, 06 Jun 2018 23:14:01 +0000 Original-Received: (at 31692) by debbugs.gnu.org; 6 Jun 2018 23:13:05 +0000 Original-Received: from localhost ([127.0.0.1]:37215 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fQhc0-0006Cd-UL for submit@debbugs.gnu.org; Wed, 06 Jun 2018 19:13:05 -0400 Original-Received: from mout.web.de ([212.227.17.12]:60401) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fQhbz-0006CA-LL for 31692@debbugs.gnu.org; Wed, 06 Jun 2018 19:13:04 -0400 Original-Received: from drachen.dragon ([188.110.196.170]) by smtp.web.de (mrweb102 [213.165.67.124]) with ESMTPSA (Nemesis) id 0LkhBY-1g18t92eOa-00aUAg; Thu, 07 Jun 2018 01:12:55 +0200 In-Reply-To: <83zi08vufl.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 06 Jun 2018 17:52:30 +0300") X-Provags-ID: V03:K1:fWA7eNDAAtBKZ+uEwgGf69tMu3ZKoCw/LS7tCx+xNP/a3YnmO66 9mIE9ZgJ910BrjI1jMTzwW4+7bhPB8qjmHQiBgNb6HAyjDEZUGtiXzO5lqnHY8mpqdNMOb5 70GkU0OAZix7PjWNM6XdpsMXcApDuZv2rH9VOznY08Xh8ZEvAUCHUNheh8LV8VJhXFmKaVN TzPVeJSBLCJibPxC496nQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:wxzO2+VrFT8=:dWZYpNPhx56vY3EwBUQdvW NoFVkFUCSlvSo+fUvW1MhsOmIJSPE1JmOW553vs5YyMKZJX3YRqH2dwpeFwLH++P5yxtSfMD+ ax2JY3nog629qzKxlVXM/uDaPs+aMIEW+sJ2CO2w+C7s/XkgoLFVVCWRfPWdbU+O15/chvaJS 4eHwvMbYgTw4iDFloxbF7i/RQxeCNZpccCRbqUtV4NIi2Eisd3V4PNW9rNw2bGmofc1OlejEE dtM3zTuwW3bpn1vM8Y6e+A7Tb0E9wAERCRZCSApdG0P1nnjqcu6g75vEJ4rHLyuk9OIx12UVS Dg2gC5mWTwjrAVJOxPD3V35HP8G3KYtFxBYNAz3LZRodRJuoe6z12Fu0MIxp2C7Tdax4x5yL3 6Tq3lodFSnrYIvOA5pvftZIUtKhvqbmLFFENqWDc5xFKA+yrpLSrzMEobkgzpZgiksksaNjM4 nKXpot8FFY0XlLTiMHW5cvEqomfPQLplRJaz3UtL17V4Xo8oIL1N+VCbsyiQsGnvIPyAYF4Li CsXX/CjEe/hurJWiJ64KsYhaoZvhk+CWHAmnBsV/Dq4KdNI8nCAXh0vALdFm9pUxCluHy6s1x xJ7yrfMvAHeTQwsgCp0el/HVIzFBcZQIhDeJAbIcRvicO/f4FFQQTo6rTCtCZtN2FBMuXiuoB 38HhRVXs5+FTtsuciPkVrEbPN2jZmLccJIKNOLd84OcMN60oz7tI/7xmxr+a8VDFTiCXeSdCE 0DqnVVYU1DECV+2tV9/MtylNMcvIdJSm56eGPc6Kl38YLOw7hiJnyCUqTg+X1fWzgg+NsEC7 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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" Xref: news.gmane.org gmane.emacs.bugs:147111 Archived-At: Eli Zaretskii writes: > Not necessarily. The forms of the body are aborted, as documented, > and that includes discarding all input, so the character that > interrupted while-no-input gets discarded as well. I don't think discarding input is intended. If you replace `sit-for' by something else (a loop causing a delay, or a sleep for), it doesn't discard the input. > > For `aggressive-indent-mode' - I think they should use an idle timer: > > Add something to `post-command-hook' that activates the timer, or > > resets > > the idle time when the timer is already there. When the timer fires, > > you don't need `sit-for' - and the problem only occurs when > > `while-no-input' and `sit-for' are combined. The timer just calls the > > aggressive indent function wrapped in `while-no-input'. > > I actually don't understand why not use just sit-for. Why is > while-no-input needed on top of that? Seems you never used `while-no-input', or at least not for the same things as I did. AFAIU the purpose of `while-no-input' is to make frequently occurring "background" operations that last long enough to possibly interfere with user interaction interruptable: hitting a key aborts the operation and the editor is corresponding without delay. And the command corresponding to the hitten key is executed as normal. Of course you need to ensure that the aborted code always leaves thing in a consistent state. An automatic indent mode is a good example: you potentially want re-indenting after any editing operation, but it is potentially slow and would cause delays. Using `while-no-input' let's you interrupt the indentation operation and continue typing. If you later make a long enough typing pause, indentation will finish. The `sit-for' is there to avoid that indenting fires immediately after hitting a key, so that interrupts are less common. That's what I think is the purpose of `while-no-input'. I use it here and there, and never saw the behavior we see here. It seems this only happens if a `sit-for' is aborted inside the scope of a `while-no-input'. Michael.