From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.bugs Subject: bug#62194: 30.0.50; Two Eglot-over-Tramp tests are failing on master, passing on emacs-29 Date: Sat, 18 Mar 2023 13:23:38 +0100 Message-ID: <87bkkqz1rp.fsf@gmx.de> References: <87wn3jue1q.fsf@gmail.com> <87edpqjqsv.fsf@gmx.de> <874jqmjl0s.fsf@gmx.de> <875yb1pxai.fsf@miha-pc> <87ttykj45i.fsf@gmx.de> <878rfw51mh.fsf@gmail.com> <87pm98iw1e.fsf@gmx.de> <87fsa43f36.fsf@gmail.com> <87sfe4eh09.fsf@gmx.de> <87wn3g1ssd.fsf@gmail.com> <87fsa3ejxq.fsf@gmx.de> <87pm97eibv.fsf@gmail.com> <87mt4az9eo.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="34649"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 62194@debbugs.gnu.org, miha@kamnitnik.top 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 Sat Mar 18 13:24:22 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 1pdVbh-0008sj-My for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 18 Mar 2023 13:24:21 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pdVbR-0006sM-Ch; Sat, 18 Mar 2023 08:24:05 -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 1pdVbO-0006rf-Sp for bug-gnu-emacs@gnu.org; Sat, 18 Mar 2023 08:24: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 1pdVbO-0005y8-GR for bug-gnu-emacs@gnu.org; Sat, 18 Mar 2023 08:24:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pdVbO-0001gT-Cr for bug-gnu-emacs@gnu.org; Sat, 18 Mar 2023 08:24:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 18 Mar 2023 12:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62194 X-GNU-PR-Package: emacs Original-Received: via spool by 62194-submit@debbugs.gnu.org id=B62194.16791422306452 (code B ref 62194); Sat, 18 Mar 2023 12:24:02 +0000 Original-Received: (at 62194) by debbugs.gnu.org; 18 Mar 2023 12:23:50 +0000 Original-Received: from localhost ([127.0.0.1]:46504 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pdVbC-0001fz-9r for submit@debbugs.gnu.org; Sat, 18 Mar 2023 08:23:50 -0400 Original-Received: from mout.gmx.net ([212.227.17.20]:57087) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pdVbA-0001fa-CH for 62194@debbugs.gnu.org; Sat, 18 Mar 2023 08:23:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1679142221; i=michael.albinus@gmx.de; bh=a1K0z1HDQAsfl6Jz0gYqz2VzFrcc7qf0BumFfy6TRJo=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date; b=tcCBQnnMhVf3BHNFVruleStQaqWoQ2KYo7raLjnnY2kVAvbllOw9mwPuXvcIFGa8p plYEt/CL/HRNsH+OPywNmQNibQPWTFXrh4HYyflfAqFK1sv3FhyyrETgDYvgTT+HSK CTLYVkJWBs3JQ1iLZ+qwAnOa8DnHseizayZgC2hws3IlVg1kEtbDvmlgUnx99cSSTD h4G5AqrbhofLvCGxOKkmn9TNzS0AXgHGOfKOMBuvhvR0nHSlZJ/WxDk37+XBdG4d+t HIwWdpym4fnMkZLxWbvjddb49RhI9uPHt5LGxO0KC9jpOkLtcrsxUQRfvdxjWBzPMX HVzv0Ig65gr0w== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from gandalf.gmx.de ([185.89.39.19]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1Mwfac-1qSb7H1z7y-00y6xZ; Sat, 18 Mar 2023 13:23:41 +0100 In-Reply-To: ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Sat, 18 Mar 2023 11:29:21 +0000") X-Provags-ID: V03:K1:2JIa7BwTeD7UAMz0i97/mcN1Nm5b27N3/zJA6zuKvsXKJub3pOC zG59NrC8rP31vaLvzdC0Almjf/KdCPBuJufRzAtaGd3D7r17rxr0XO2VgqAJgh9f8jlEP40 iOpyEgTvC/2CR47/K0w1OQTpDXWONVWQGb5vZZ9BQUzfcnCS0b3kSHQN/jOtqfBvVTQ1YUA 0GjtMPvQVcdNOhk9HmGOw== UI-OutboundReport: notjunk:1;M01:P0:oROOG5KWRYk=;t415ZmYA09cYlDhBSJD2OewAO+Q SsYU/IUS3gzRDw4o4C5VxqWgfFdneOVGNEqAN5A5e4ATOzLt+vVihAO1rSe9kDBAVclUSbqMo ax5qdlg7EuhhY3dghej5/VaPGsJmFgIh1PNoOdw7xs+gDJymMSXBzbwMCV59h3lVvgKAFrGch tujL2sD4HoiICdEdYN+zqFpTKSpfKklcOQUYWxUk0zIxSj3kermSGrGSU7Tg7HsPYbZwKwBxu qOa2VTr5CE3u2uq3/wi6Erl+ZC3wHpCRFPyhQRvSEFprPjXcTQSu1cDasMxcT4Yss+064uGhM 5KPfbnrq15Ahn9yBU0WmF/9ztQwHOCQ5DS2CMaSGSaIHP5/Pi02dcJeowtQ8CU4HBHS7g0UL8 5cSnL5BY48w/uDXn6wJgqF45BenSPZUTQvcIXbcQIYBtBg6OTGuSjxJA78msBvZzv7NcPfDis +qCGyr9JSD5vWPU3yTLWP9c8o/6MVm1RGfmg24NlNz9IPfKdKd4CXilmOakPWm9NdTud5moSs UhnE9rpa5gOTenzxwB8k/GKoAxTDvsjaLrqnAarvevg+LrcDeyR0QT6aiGSDlvd9LhHhH4sQJ JU8cITaNbQExWOXs6XSkO1Zj5T73jghML5xdrCMBbXJAhlG8i4RQ9aOxQq/x4aaqJhzOCKNhC f5clQa5RFBcmSuuPqdqMx7DoDKx+Ur/I04pjCMaQ4ylruFAMZ/jUXJB5cTRscVriY35aNYa/T 6JARJE1zb+vSv7yZUNVBo6JwUEVmEnSRXAYa9uw5e2B3Vj8iZ3kVZ8YJd+960md7WAv2AfFb 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:258169 Archived-At: Jo=C3=A3o T=C3=A1vora writes: Hi Jo=C3=A3o, >> So I propose we let the state as-it-is in master. The relevant tests >> pass successfully, and we have your workaround in eglot.el, which makes >> the situation a little bit better. > > I propose we still revert the two of your latest patches. The situation > stays exactly the same in practice for now (bug#31350 broken, this bug > fixed, workaround in place, no-one knows what is really happening), but > with the added advantage that the code is still the same as in emacs-29. Nope, I'd like to keep the changes. It is the basis for further work on the problem. And these changes will also be in Tramp 2.6.0.3. >> Just one remark: perhaps you could >> change this to >> >> --8<---------------cut here---------------start------------->8--- >> (let ((default-directory default-directory) >> ;; bug#61350: Tramp turns on a feature >> ;; by default that can't (yet) handle >> ;; very much data so we turn it off >> ;; unconditionally -- just for our >> ;; process. >> (tramp-use-ssh-controlmaster-options 'supp= ress) >> (tramp-ssh-controlmaster-options >> "-o ControlMaster=3Dno -o ControlPath=3Dn= one")) >> --8<---------------cut here---------------end--------------->8--- > > >> For the Tramp < 2.6.0.3 it still works, because >> tramp-use-ssh-controlmaster-options is non-nil, and >> tramp-ssh-controlmaster-options is used. Starting with Tramp 2.6.0.3, >> the value `suppress' forces Tramp to compute its own >> tramp-ssh-controlmaster-options, which might be the same, or not. But it >> is Tramp's responsibility to DTRT. > > Makes sense. If it's just this change, you can push this yourself. > Thanks in advance. Pushed to the emacs-29 branch. >> Note that I have plans to enable shared connections also for PuTTY, by a >> similar option tramp-use-shared-connection (or similar, not decided >> yet). But this will be relevant for MS Windows users only; I don't know >> how many of them use eglot. And it will definitively be in Tramp 2.7 >> only. >> >> As proposed. we shall close *this* bug. The reported problem is fixed, >> and for everything else we have bug#61350. > > OK. > > Just a heads up, I asked for bug#61350 and this one to be "merged" > earlier. Don't know what debbugs did about that, but didn't see any > practical effect This are two different bugs. Bug#61350 is about using a shared connection, and this is still open, although mitigated by Eglot's workaround. Bug#62194 is about a patch which tried to fix bug#61350. This patch has been reverted, and so there's nothing left to do for bug#62194. It can be closed. >> > FWIW, removing the JUST-THIS-ONE make Thomas' example always pass, but >> > it has other implications like the re-entrancy thing, which I don't >> > understand. >> > >> > I don't have any better ideas at the moment, other than just biting the >> > bullet and reading Tramp's code very closely. I'll try my hand at >> > adapting a process-filter into it as I described in bug#61350, but I >> > don't know if I'll manage of course, since I'm not closely acquainted >> > with the API. >> >> I will continue to bring threads into play with Tramp, again. Slow >> progress only. But perhaps, it helps to improve the situation. > > I think you should consider bring stuff _out_ of Tramp instead of _in_. > > Consider removing tramp-a-o-p entirely, and segregating/segmenting > messages in a process filter. This segregation is entirely textual > (no fs primitives) and does run the risk of reentrancy. Then -- for > sync APIs -- 'throw' the complete message into whoever is blockingly > waiting for the answer with (catch ... (while (accept-process-output p))). > > I've given a working example in bug#61350. If you need timeouts > I can show you how to add them. The problem is even more complex than discussed so far. All of asynchronity can happen to Tramp's reading of process output. Process filters and process sentinels from other processes, timers, callbacks from file notifications or D-Bus events, whatever. I'm not convinced (yet?), that moving Tramp's process output reading to a process filter will solve it. There is also the additional problem in Emacs, that process filters do not cascade. Any package can activate an own process filter, even for Tramp processes, and Tramp would be lost then immediately. > Jo=C3=A3o Best regards, Michael.