From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#61350: Eglot over Tramp freezes with large project Date: Thu, 16 Mar 2023 22:04:57 +0000 Message-ID: References: <87y1ootw2t.fsf@gmail.com> <87pm9fk6ht.fsf@gmx.de> <87mt4jzf8q.fsf@gmail.com> <87fsabh2z2.fsf@gmx.de> <87edpvxu7w.fsf@gmail.com> <87bkkzgyb8.fsf@gmx.de> <87lek2x09t.fsf@gmail.com> <875yb646d1.fsf@gmx.de> <87fsa7mw9x.fsf@gmx.de> <87fsa7l6o6.fsf@gmx.de> <87a60fl4p7.fsf@gmx.de> <878rfx6bqe.fsf@gmail.com> <8e031bc5-7ac3-620e-b1ca-aaa872b3cdde@gmail.com> <87lejw3jx4.fsf@gmail.com> <874jqk3cxp.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13082"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Thomas Koch , Jim Porter , Michael Albinus , 61350@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Mar 16 23:04:33 2023 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 1pcvi4-00038m-Ot for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 16 Mar 2023 23:04:32 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pcvhe-0007hX-Mj; Thu, 16 Mar 2023 18:04:06 -0400 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 1pcvhb-0007gV-3m for bug-gnu-emacs@gnu.org; Thu, 16 Mar 2023 18:04:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pcvha-0004sn-8Z for bug-gnu-emacs@gnu.org; Thu, 16 Mar 2023 18:04:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pcvhZ-00084y-SP for bug-gnu-emacs@gnu.org; Thu, 16 Mar 2023 18:04:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 16 Mar 2023 22:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61350 X-GNU-PR-Package: emacs Original-Received: via spool by 61350-submit@debbugs.gnu.org id=B61350.167900419530994 (code B ref 61350); Thu, 16 Mar 2023 22:04:01 +0000 Original-Received: (at 61350) by debbugs.gnu.org; 16 Mar 2023 22:03:15 +0000 Original-Received: from localhost ([127.0.0.1]:43259 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pcvgp-00083o-33 for submit@debbugs.gnu.org; Thu, 16 Mar 2023 18:03:15 -0400 Original-Received: from mail-oi1-f170.google.com ([209.85.167.170]:36551) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pcvgn-00083c-Jz for 61350@debbugs.gnu.org; Thu, 16 Mar 2023 18:03:14 -0400 Original-Received: by mail-oi1-f170.google.com with SMTP id bi17so2459203oib.3 for <61350@debbugs.gnu.org>; Thu, 16 Mar 2023 15:03:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679004188; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=6x5kSSIHZfb5u/tJmuCaiBcRW9aPsNpA0xK1CWFFVaE=; b=UMZGHG+EXnEbyzVwi16PgejMsbQoS9rpYPwptUWs57GLfHK9PqMsi088e5KLnE7frk OlPJ/BzzeSI5tsmnzUwRCqvuy4heGwMDiBg3PjBD61SIpx2+2GxGcXZLDGoXF1L7WUEp eLhmze/+zG9AXt8wtnOAnxxVpN6uAtIKtYZLC08hCkZ3GCSIEHE94gpLexogWCLixVT4 7FKJQAU6Bj8WsHTPz6jTvRPd0RCsyeX0WLydZWJmiX8t5JcIR52PXj1IzfIAIUVJXM0z Wv9IycVxf23+GfjRxiKkiBVQsZBa201COkyOKQr0xEyyzQqw/nWJ4PCpBHULPCVrWP05 5bnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679004188; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=6x5kSSIHZfb5u/tJmuCaiBcRW9aPsNpA0xK1CWFFVaE=; b=GsABjjqhB+sPX1vsoO7ej5GmnqcYYydAqoVvzVhzQcvk2Pdi/9foFDOXPl/RNplCFi AVQrZ582+tJOkIVCRrzTyHIyNfkkj7pQb8Ugx4GI5DLws8pD+JYMYENFFiG4I2T1XqmB aXBm0yxyiQud0nCb3PiD64hJth+mwpD5fVL7GCU3EFcOxma88i1BdynHJdaQkXS5o/Dg G883U9ViXZZTsRkCN6/XKNKhwjr4DaqwYx6s18+TDL8rNSjbq7CJ/rT5msTPaqzax8NZ Ofh2KAQDmMJlShaSqssllAJjTSXcGbCR3JEjzzw3uaVmvakM6gBhVgAdxK+B9bY8louZ gT9Q== X-Gm-Message-State: AO0yUKW8ZQp3KM2cekw5U90f9VA5au9E2V7Cf51IqgPWjgUsTbN8jdlv HP48x/Xf7IiuKO1SEfXGILbNqvQB3UXtz5T+hTE= X-Google-Smtp-Source: AK7set8arG69Q331GF8DueQ2gywwp74qS7dDvLjVUcwr2VzE4ivfGjQf3A+2ZEClJe4yRGX1SwTTlnU5wjhIgs+8DYU= X-Received: by 2002:aca:6505:0:b0:386:a109:57c8 with SMTP id m5-20020aca6505000000b00386a10957c8mr2368016oim.5.1679004187950; Thu, 16 Mar 2023 15:03:07 -0700 (PDT) In-Reply-To: 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:258040 Archived-At: On Thu, Mar 16, 2023 at 8:36=E2=80=AFPM Stefan Monnier wrote: > I think doing more of the work asynchronously (i.e. from the process's > filters/sentinels rather than after `accept-process-output`), like in > this example, is virtually always better, yes. > > The use of `catch/throw` is not applicable to code which may be used > asynchronously (i.e. where we don't know that there's always a `catch` > waiting for our `throw`), so I hope we can get code to work just as > reliably without using `catch/throw`. Of course, normally you want the async/sync pair of primitives: (defun hal-async-command (callback) "Send command, call CALLBACK." (when (process-get hal-proc 'callback) (error "HAL only takes one command at a time") (process-put hal-proc 'callback callback) (process-send-string hal-proc "OPEN THE POD BAY DOORS!\n")) (defun hal-sync-command () (catch 'hal-done (hal-async-command (lambda (r) (throw 'hal-done r)))) So what I mean is: * when synchronous APIs are needed (that is presumably what TRAMP needs, according to you) then *do* use catch/throw/filter/accept-process-output * when async is needed, use callbacks. You can mix in the upcoming emacs-io.el/futur.el/whatever frameworks, but when processes are involved, some variation on that technique should be used somewhere. My main point here is that this bug's root cause is the lack of good filter+accept-process-output design. I just think that basic tools to achieve that design are already in place and reasonably easy to grasp. I'm not opposed to newer tools. And I already mentioned that the above approach can be enhanced to include timeouts and cancellation on user input (for the latter, sit-for is usually preferable to a-p-o). > This mission is too important for me to allow you to jeopardize it. :-) Sorry to interrupt the festivities, Dave Jo=C3=A3o