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: Tue, 28 Feb 2023 11:33:54 +0000 Message-ID: <871qmarplp.fsf@gmail.com> References: <87y1ootw2t.fsf@gmail.com> <69968923.705640.1677163650760@office.mailbox.org> <87a613f0b7.fsf@gmx.de> <87r0udvmzr.fsf@gmx.de> <878rglxrzm.fsf@gmail.com> <87cz5wmjbx.fsf@gmx.de> <87h6v8f7u9.fsf@gmail.com> <87o7pflfcd.fsf@gmx.de> <87wn43e9ht.fsf@gmail.com> <874jr6oont.fsf@gmx.de> <87sfeqd4zi.fsf@gmail.com> <877cw2m5wm.fsf@gmx.de> 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="13740"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Thomas Koch , eliz@gnu.org, 61350@debbugs.gnu.org To: Michael Albinus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Feb 28 12:33:26 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 1pWyEX-0003RP-Qn for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 28 Feb 2023 12:33:25 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pWyEG-0003k2-SF; Tue, 28 Feb 2023 06:33:08 -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 1pWyEE-0003ji-SP for bug-gnu-emacs@gnu.org; Tue, 28 Feb 2023 06:33:07 -0500 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 1pWyEA-0004V4-S6 for bug-gnu-emacs@gnu.org; Tue, 28 Feb 2023 06:33:06 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pWyEA-00022x-DY for bug-gnu-emacs@gnu.org; Tue, 28 Feb 2023 06:33:02 -0500 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: Tue, 28 Feb 2023 11:33:02 +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.16775839337787 (code B ref 61350); Tue, 28 Feb 2023 11:33:02 +0000 Original-Received: (at 61350) by debbugs.gnu.org; 28 Feb 2023 11:32:13 +0000 Original-Received: from localhost ([127.0.0.1]:49825 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWyDM-00021W-JA for submit@debbugs.gnu.org; Tue, 28 Feb 2023 06:32:12 -0500 Original-Received: from mail-wm1-f46.google.com ([209.85.128.46]:38484) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWyDI-00021F-BQ for 61350@debbugs.gnu.org; Tue, 28 Feb 2023 06:32:10 -0500 Original-Received: by mail-wm1-f46.google.com with SMTP id ay29-20020a05600c1e1d00b003e9f4c2b623so9258973wmb.3 for <61350@debbugs.gnu.org>; Tue, 28 Feb 2023 03:32:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1677583922; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=1g74dWfZYUqpxBrDhZhbDOZntZM9I+bxFn9YPt0DPvY=; b=EnVbgPh7CH+yVOL7oe6BfdJerMfngY16OErzkMD9eVXong9t3zS8TbVJ6JxJSc96oA r2GITVYOnWhaonVE5gWQmlTJJT/1jLdyKD6h8LxijsAthFPc5AsRygMaRPua4Zq8mj4Y UTsIXn2OZAvWIc5W0TWJ8KixW9K5FJVUioUzSoC6335p06mJsZeRpr0RbsZrS0eb+LFa nxUZtL26MM2BnZRfFX59k3+5XUDBGbfassFWLQ4alpczoZB5hEhy7tznxDNHiMLPQ7Qb FSwCMZRGQ+szb2WYqKQ22ufZ25dp+SA4JWMxerNs4B6fqZ9CWZ3QGr+ghKD6XGSuokm2 rQEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677583922; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=1g74dWfZYUqpxBrDhZhbDOZntZM9I+bxFn9YPt0DPvY=; b=N50aEsMuUYSsperNGf4Hxf6gmq6KpJgh68C5jAdZxaccbeKeLVWDumsx1i3guVJRx8 K3QldMOLz9btAqBxZgSgdDvL8+WXqtGLDc83U9uaGtl5Qpc0Tegk/uz/98BR73I9WuT7 JoLuWuSum/OgAZOOzYWPziBglinWXUpEefaDsoLs2/z9qHmd5lW6myi9PW1hjTrKd1ZQ wkPSIUOm9uZEjyf40AnClTNxgGM1RUtQg81Lp3uBUNH5gxAeQ69YdrEIvaGYPb7oHsAo eEDbmutl5auQ58JnUijSlyjJHXNQF1qzUE4Wgadu9//QB8tSnggNg+OvMNEVQpi2XZkH ID/g== X-Gm-Message-State: AO0yUKUs7PuiDetL+hRpZnUr+RNSFD5iMgB3xtvGMiZWC33aP+Jtcok2 ZLm4QaWinG/OSkDsKPPkpw8= X-Google-Smtp-Source: AK7set8evdb6Fh5zMr6Q/fTpykBBLHZ4ybhBVXugvE2vVyQUVlEbUC9H0edq6iyAQ15t3tGVh7fvIA== X-Received: by 2002:a05:600c:319e:b0:3eb:2de8:b74e with SMTP id s30-20020a05600c319e00b003eb2de8b74emr1777283wmp.27.1677583922180; Tue, 28 Feb 2023 03:32:02 -0800 (PST) Original-Received: from krug (87-196-72-142.net.novis.pt. [87.196.72.142]) by smtp.gmail.com with ESMTPSA id i13-20020a1c540d000000b003db06224953sm12422163wmb.41.2023.02.28.03.32.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Feb 2023 03:32:01 -0800 (PST) In-Reply-To: <877cw2m5wm.fsf@gmx.de> (Michael Albinus's message of "Tue, 28 Feb 2023 11:38:17 +0100") 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:256947 Archived-At: Michael Albinus writes: > Jo=C3=A3o T=C3=A1vora writes: > > Hi Jo=C3=A3o, > >>> It is stable. Except in the case of large amount of data, which is >>> exceptional for Tramp usage. >> ...is it though? :-) Can a feature that hangs when presented with more >> data than usual (however one defines that) be considered stable? > Tramp supports ControlMaster since Emacs 24. Eglot is the first case > I've heard of problems. I don't deny it That could be because, as far as I understand, Eglot is the first "major" package to use the transparent (make-process ... :file-handler t) which, AFAIU, means that Eglot's process, which doesn't really transmit _that_ much data, is piped transparently through Tramp's process managing the remote file whose buffer M-x eglot is executed in. >>> It is essential. I have been beaten by many Tramp users to support it. >> I'd say something "essential" is something you can't live without. But >> that doesn't seem to be the case here. > Ohh. You haven't seen how much Tramp has been blamed because it doesn't > support it out of the box. I understand, but it's the occasionally-exploding racecar all over again. I understand your reasoning: you're betting that it's acceptable for the ocassionally-exploded user to learn opt-out for a slightly slower car. The thing is they will probably blame the steering wheel, Eglot, because -- Tramp being "transparent" -- that's what they see. Ideally, we would just fix this. It would be nice to understand what actually happen and what information is lost, presumably to ControlMaster's gremlins. I think bringing in Eli's knowledge of process.c internals could be beneficial here. > Currently it's not possible. I'll investigate a way to disable > ControlMaster per process. By this, the main Tramp process and other > processes on the remote host could still profit from the performance > boost, and other processes (like Eglot) could opt-out. One thing I don't understand, here and in other bugs, is the "process" model of Tramp. Here are some questions. Apologies in advance if some of them are in the "FM". 1. When I open a single remote file on a remote host, I am creating Tramp process, I presume. 2. If I kill this buffer and re-visit it, is the Tramp process re-used somehow or is a new one created? 3. If I open another nearby file on the same host, I am sharing that Tramp process? 4. What about in a different host? 5. Is there any way to get an overview of which Tramp processes are "responsible" for each set of remote files? 6. Now if I M-x eglot in a Tramp remote file that I had been working on Eglot-less for a while, is the Eglot process tunneled through the existing Tramp process, reusing it, or is a new one started? 7. If an existing process is reused, is there any way to force Tramp to open a new one, perhaps with slightly different configuration options? Jo=C3=A3o