From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Thomas Koch Newsgroups: gmane.emacs.devel Subject: continuation passing in Emacs vs. JUST-THIS-ONE Date: Sat, 11 Mar 2023 14:53:09 +0200 (EET) Message-ID: <627090382.312345.1678539189382@office.mailbox.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14428"; mail-complaints-to="usenet@ciao.gmane.io" To: "emacs-devel@gnu.org" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Mar 11 13:53:47 2023 Return-path: Envelope-to: ged-emacs-devel@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 1payjK-0003Yh-M7 for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Mar 2023 13:53:47 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1payiw-00045b-6N; Sat, 11 Mar 2023 07:53:22 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1payit-000430-Rn for emacs-devel@gnu.org; Sat, 11 Mar 2023 07:53:20 -0500 Original-Received: from mout-p-102.mailbox.org ([2001:67c:2050:0:465::102]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim 4.90_1) (envelope-from ) id 1payir-0007ni-IO for emacs-devel@gnu.org; Sat, 11 Mar 2023 07:53:19 -0500 Original-Received: from smtp102.mailbox.org (smtp102.mailbox.org [IPv6:2001:67c:2050:b231:465::102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4PYjWp2kRHz9sTk; Sat, 11 Mar 2023 13:53:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=koch.ro; s=MBO0001; t=1678539190; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=JrbGNHdwuWUQzUR16u69bfXa1ZHYP0LJqzLtI98UaDg=; b=ZAf3XisulaObmSmvVZAKIU0AXRJKnIqagHSbP5d8TGlCERmWCLh5xvohkNAnv+Wc5qu8qI PJqcmt+lPz8x4Ie/8rldx/ohaxLqVcl8BxKvbHslpq09vFHv3x6SCMc5dccNLmtub5Puq4 vpz+3sA5kAN/ULD99biLei5ixcqDTO6AeeKZupS31HD1MQ7ogKTuoRLEThwKWgXMWauUfM hUqYbJ7E99rkd0EZCW8R2B4u/BGKePTsCUX2CxkrnKANxfHS15JBy8lR524Js83pTJdy2P MPW52yW7ELHlAsue5rS27XJY5jEhOUjx1V00qMiqsumGWverAnyYmlzF1IVysA== X-Priority: 3 Importance: Normal X-Rspamd-Queue-Id: 4PYjWp2kRHz9sTk Received-SPF: pass client-ip=2001:67c:2050:0:465::102; envelope-from=thomas@koch.ro; helo=mout-p-102.mailbox.org X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:304302 Archived-At: TL;DR: (Why) is there no standard way for continuation passing style[1] ("event driven") programming in Emacs? During the investigation of an Emacs freeze[1] while starting eglot over tramp, we made a couple of observations. It was proposed to me to share these observations with you. I don't know elips or Emacs internals though, so apologies for any errors. [1] https://debbugs.gnu.org/61350 Bug #61350 happens because Tramp calls accept-process-output with JUST-THIS-ONE set to t. Tramp does this since Bug #12145[2]. However it seems, that this bug should have been rather fixed in function `find-dired` instead. (See following separate email on this.) [2] https://debbugs.gnu.org/12145 The JUST-THIS-ONE argument was introduced with this entry in etc/NEWS.22, emphasis from me: """ *** Function 'accept-process-output' has a new optional fourth arg JUST-THIS-ONE. If non-nil, only output from the specified process is handled, suspending output from other processes. If value is an integer, also inhibit running timers. THIS FEATURE IS GENERALLY NOT RECOMMENDED, but may be necessary for specific applications, such as speech synthesis. """ The argument was discussed here: https://lists.gnu.org/archive/html/emacs-devel/2004-08/msg00141.html and introduced in this commit: https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=107ed38d4bdec03002b2a23619e205722cd5b8d1 I don't even think that the original motivation for introducing JUST-THIS-ONE was valid. Unfortunately there was not much discussion about it. It was argued, that it would be hard to make a process filter function reentrant. And I think that this was an invalid root cause analysis to start with. First, the emacs manual says[3]: "Note that if any of those functions are called by the filter, the filter may be called recursively." - So one should make the filter reentrant, If I understand correctly. [3] https://www.gnu.org/software/emacs/manual/html_node/elisp/Filter-Functions.html Second, the manual further says: "Quitting is normally inhibited within a filter function". This indicates to me, that a filter function should be (mostly) "side effect free" besides putting its input somewhere (e.g. in a buffer or message queue) and trigger an event if there is enough input for further processing. This also reduces the risk, that the function could be called recursively in a damaging way. It seems to me, that there is not yet a standard way in Emacs for continuations (or event driven programming) although the Emacs Wiki refers to the emacs-deferred library: https://www.emacswiki.org/emacs/ConcurrentEmacs Because there is no such library in Emacs, people either write their own code for continuations (eglot?) or do too much work in a process filter function (speechd-el in 2004 which led to JUST-THIS-ONE). While I don't know elisp, I unfortunately had to do JavaScript. Like Emacs, JS is single-threaded. While I share the sentiment about JS, there are still things to learn from it, e.g. event driven programming. See also: - 2011 emacs-dev discussion: https://lists.gnu.org/archive/html/emacs-devel/2011-05/msg00575.html - 2016 Blogpost https://jyp.github.io/posts/elisp-cps.html - https://stable.melpa.org/#/deferred - https://www.gnu.org/software/emacs/manual///html_node/elisp/Transaction-Queues.html - Maybe: https://elpa.gnu.org/packages/fsm.html