From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#45117: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer Date: Thu, 10 Dec 2020 14:46:02 -0500 Message-ID: References: <87h7ow4j4o.fsf@gmail.com> <83mtyo71dh.fsf@gnu.org> <877dps47ge.fsf@gmail.com> <83360g6xlt.fsf@gnu.org> <87im9b2pds.fsf@gmail.com> <83k0tr5700.fsf@gnu.org> <87360d3dud.fsf@gmail.com> <83eejx4rd6.fsf@gnu.org> <87r1nx1vtd.fsf@gmail.com> <87mtyl1v6y.fsf@gmail.com> <87h7ot1ona.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6252"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: 45117@debbugs.gnu.org To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Dec 10 20:47:17 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1knRuG-0001Pp-SB for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 10 Dec 2020 20:47:17 +0100 Original-Received: from localhost ([::1]:34372 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1knRuF-0006Ia-Tf for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 10 Dec 2020 14:47:15 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58634) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1knRu2-0006GF-U4 for bug-gnu-emacs@gnu.org; Thu, 10 Dec 2020 14:47:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56009) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1knRu1-0000UI-Rq for bug-gnu-emacs@gnu.org; Thu, 10 Dec 2020 14:47:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1knRu1-0007Y8-QN for bug-gnu-emacs@gnu.org; Thu, 10 Dec 2020 14:47:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Dec 2020 19:47:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45117 X-GNU-PR-Package: emacs Original-Received: via spool by 45117-submit@debbugs.gnu.org id=B45117.160762957428957 (code B ref 45117); Thu, 10 Dec 2020 19:47:01 +0000 Original-Received: (at 45117) by debbugs.gnu.org; 10 Dec 2020 19:46:14 +0000 Original-Received: from localhost ([127.0.0.1]:39322 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knRtF-0007Wy-HF for submit@debbugs.gnu.org; Thu, 10 Dec 2020 14:46:13 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:24485) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knRtD-0007Wm-S0 for 45117@debbugs.gnu.org; Thu, 10 Dec 2020 14:46:12 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 23A34440BC6; Thu, 10 Dec 2020 14:46:06 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 3860C440A43; Thu, 10 Dec 2020 14:46:04 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1607629564; bh=inlGEbgZsTNAOckb9T9XVzsWx6okGI0A42CTLLU/v54=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=lkx32tqnbiBsEiLVdGJLK2yO9QDZpw/fdAlxJC1BcYun5ZoNLqEhC/mJLO/3hmV20 TG055F4oJJHHRo647WGesY5/ULxnq+JdC4mT6Nq6YAkTu/cJat6x3OQ4tGXBkWY3tx 8XTuLIchXDHAdQ/32eCLrqQW69MOw/XEYGJsoatDPMrc8iqGLULKBwT3zusHeKG3pQ tZrtcFNgrbvE931+VzsKWUN+GL+gVStLzpafNyZbgGbwVA8X5f+bOzNqj8bhUhIlS3 6IyymVmjKdQkhAQ6/ca4AbH55+wcRhH6vKoskKXP63JDJC92646vxJMNklveE3mek9 hkM86lEKHttMg== Original-Received: from alfajor (69-165-136-52.dsl.teksavvy.com [69.165.136.52]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id BE69E1203AB; Thu, 10 Dec 2020 14:46:03 -0500 (EST) In-Reply-To: <87h7ot1ona.fsf@gmail.com> ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Thu, 10 Dec 2020 18:50:33 +0000") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:195691 Archived-At: >> Right. And `while-no-input` should only wrap the execution of A, so if >> A doesn't complete, then presumably none of C nor B will want to be >> executed, which seems OK. > > We are miscommunicating. In these programs, B needs to be atomic with > A. When you send things into an external process, only the most naive > of external communication protocol replies immediately and synchronously > to the thing you just sent. For those super simple things, like "cat" > and "grep", your model works. No, I was no presuming such a simple model, actually. I was really thinking about "send data to the LSP server then get some answer a second or more later". >> closes the pipe in case we're exiting before having sent all the data >> (that's a good idea to do also in case a bug signals an error). > Again, this killing of the subprocess assumes the trivial case of a unix > utility. That's just for lack of a vocabulary to say abstractly what I meant. I understand that in many cases you may want to keep the subprocess (and pipe) open, in which case you'll have to do something else, but that "something" will depend on lots of details of the circumstance. >> The exact same problem affects all normal Elisp code when the user hits >> C-g, so I think the better path forward is to make sure it's "easy and >> natural" to write code which reacts correctly when it's aborted at some >> arbitrary time. We usually get that via `unwind-protect`, but if it's >> not enough we should develop better solutions rather than shy away from >> `quit`. > I get what you're saying, but there's a presumably reason we bind > inhibit-quit to t in timers (Eli?), and it's that that code isn't > triggered by a direct action of he user. Indeed, we bind inhibit-quit there because when the users hit C-g they presumably have no idea whether a timer or process filter happens to be running right now, so they don't actually mean "stop this timer" but something entirely different (such as run the command `keyboard-quit`). Note that in return we expect timers and process filters to run only for a very short amount of time, so that we can still react to C-g promptly. > Doing that for her in the library is violating the premise of timer > functions as one knows them. The contract is different for timer functions than it is for eldoc functions, yes. This is because the expectation is that eldoc functions may run for a non-negligible amount of time. Maybe we should change that so it's up to the individual eldoc function to use `while-no-input` if it needs it, but I'm not sure we've reached that conclusion yet ;-) > Yes, there is that too. While-no-input has all those Heisenbergian > effects to add to it. But this was no heisenberg, I think. I was > pressing C-n the whole time, so that's "input". OK, so `while-no-input` did its job correctly in your case. Good. Now the next question is: given that the user has hit `C-n` how should we make sure Emacs responds to it as soon as possible even though it's currently in the middle of sending a command to an LSP subprocess? Is this "sending" expected to never take a long time (in which case maybe using `inhibit-quit` could be the better answer)? What's the alternative: what could the Elisp code do to abort the communication as quickly as possible (without leaving the subprocess in an inconsistent state and without forcing a costly restart of that subprocess)? If the protocol doesn't offer any way to abort a command, maybe it could stash the rest of the data to be sent on some list of pending data so they'll be sent later asynchronously (and remember that the answer to that command is probably to be ignored because the user has moved on)? Stefan