From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: miha--- via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#62194: 30.0.50; Two Eglot-over-Tramp tests are failing on master, passing on emacs-29 Date: Thu, 16 Mar 2023 22:18:59 +0100 Message-ID: <87zg8co0n0.fsf@miha-pc> 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> Reply-To: Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6785"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 62194@debbugs.gnu.org To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= , Michael Albinus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Mar 16 22:15:23 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 1pcuwU-0001Y0-Ao for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 16 Mar 2023 22:15:23 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pcuwC-0005Uh-Ld; Thu, 16 Mar 2023 17:15:04 -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 1pcuwA-0005UR-Np for bug-gnu-emacs@gnu.org; Thu, 16 Mar 2023 17:15: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 1pcuwA-0002oq-8R for bug-gnu-emacs@gnu.org; Thu, 16 Mar 2023 17:15:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pcuw9-0006jK-ME for bug-gnu-emacs@gnu.org; Thu, 16 Mar 2023 17:15:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 16 Mar 2023 21:15:01 +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.167900125425800 (code B ref 62194); Thu, 16 Mar 2023 21:15:01 +0000 Original-Received: (at 62194) by debbugs.gnu.org; 16 Mar 2023 21:14:14 +0000 Original-Received: from localhost ([127.0.0.1]:43193 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pcuvO-0006i3-8I for submit@debbugs.gnu.org; Thu, 16 Mar 2023 17:14:14 -0400 Original-Received: from mail.kamnitnik.top ([209.250.245.214]:43672) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pcuvM-0006hv-A7 for 62194@debbugs.gnu.org; Thu, 16 Mar 2023 17:14:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kamnitnik.top; s=mail; t=1679001250; bh=ABWHjXI/V8LsQQy3N+foMs9IwwKdXAy/OMgF8cbjy6k=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=IBR9Dn4xuLpQLBmqIAEKful6dlP9X6C84bjvlQCEr5VuNKtAIm+FRx7WAvQ/4mjRO 3vr4gmg2moH5oac4hOHL1+V9SIFjR4zZTEpiHtDGuK6d+TVpmlXA5mZ6DFD25ARVj5 keG9h26zmZc48naCXMI7DdhwLznW7OtdcsEO3Bj/r2NcyECtIZzHfEwoQv3EKnDYAn GQsuoOZB45rwJEUXpHLpQaosg/SORCaL9bbidViXI0Urzl4Oa/3f+lRmeXnS1dfwcc jC/cEp6+av95SZe7Si1We+p6ZdxicgEfhJvuCm5Stl+hRwc8NwfOXz8BC7uOKUHBGq tngITKlaIFXlw== In-Reply-To: <87wn3g1ssd.fsf@gmail.com> 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:258038 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Jo=C3=A3o T=C3=A1vora writes: > From ac334523b4a7ba23a5198ad60a97456055ffbfbd Mon Sep 17 00:00:00 2001 > From: =3D?UTF-8?q?Jo=3DC3=3DA3o=3D20T=3DC3=3DA1vora?=3D > Date: Wed, 15 Mar 2023 20:02:43 +0000 > Subject: [PATCH 3/4] A simpler fix for bug#61350, a small tweak Michael's > original idea. > > * lisp/net/tramp.el (tramp-accept-process-output): Accept process > from related processes. > --- > lisp/net/tramp.el | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/lisp/net/tramp.el b/lisp/net/tramp.el > index 47173b95bea..a7406a9d80e 100644 > --- a/lisp/net/tramp.el > +++ b/lisp/net/tramp.el > @@ -5800,6 +5800,11 @@ tramp-accept-process-output > This is needed in order to hide `last-coding-system-used', which is set > for process communication also. > If the user quits via `C-g', it is propagated up to `tramp-file-name-han= dler'." > + (when-let (((process-get proc 'shared-socket)) > + (v (process-get proc 'vector))) > + (dolist (p (delq proc (process-list))) > + (when (tramp-file-name-equal-p v (process-get p 'vector)) > + (while (accept-process-output p 0))))) I think that accept-process-output with JUST-THIS-ONE=3Dnil is dangerous here. We are now allowing 'file-exists-p', 'expand-file-name' and all other functions listed in 'tramp-sh-file-name-handler-alist' to call any timer or process filter, without even documenting this. And even if this behaviour was documented, I don't think it is what Elisp programmers want. It's hard to be 100% sure that calling a simple functions such as 'expand-file-name' will work as expected in presence of arbitrary timers or process filters. Remember that Emacs can have pretty hardcore timers or process filters: In M-x shell, the process filter may call 'read-passwd', entering a recursive edit, in which the user can kill any buffer or even a process. Or with midnight-mode enabled, a timer kills buffers older than 3 days. I consider these "the problem of timing errors that usually plague parallel programming", to quote '(elisp) Output from Processes'. I'm not saying that my proposal with SIGWINCH is flawless and I agree that its unacceptable. I'm just saying that we shouldn't be quite satisfied with this solution yet, though it should be fine for some time. What I was thinking was perhaps to introduce a function called 'accumulate-process-output' which would be similar to 'accept-process-output', except that it would only save process output on the heap without calling any process filters or timers. Subsequent calls to 'accept-process-output', or more accurately, wait_reading_process_output, would then first call the process filters on the previously saved output from the heap. This solution would probably be quite complex to implement, but having thought about this problem for two days, I haven't come to any other idea. If there aren't any objections or better ideas, I could start working on it after I finally receive copyright paperwork. > (with-current-buffer (process-buffer proc) > (let ((inhibit-read-only t) > last-coding-system-used > --=20 > 2.39.2 > --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJHBAEBCAAxFiEEmxVnesoT5rQXvVXnswkaGpIVmT8FAmQTh8MTHG1paGFAa2Ft bml0bmlrLnRvcAAKCRCzCRoakhWZP6KuEAC4PgMc1ezRKM1h4C9D7t+iAt9EgREL 5vBqPLOX+fj7JZ2dTcwwbn+AuVxOGTTVs+sj+VUvOl0x0O/SaGgjaAP+tOUdvqQg OpJ5nKmhC7OL2V0gayjQTWwFHuaPa1MaqXNS98kdIdO2Yr4N/aqkg04K88EyiKka 57VIARTfREQtUMgKM/ex3SJzr4f6bPWszQ9PGRbK+F3tzbQk6sY/E7V6G/5IdqTh DRjTbmqE4A1H3dqzwm+UUr0P9XMYkEiFgKM+iUDSFjV1oKsy2snzh53058e7ERo4 3r6ujUbj6xPDkxMxMV2C/eMuh/EafGRWQkTz95ffPIIKqJghQSsKptejj7CjlOT3 9ns2rATfhioDION1DFKsHghIuRVEV00lBBiAde/lavSaxwjBoAT2UPkavl1oLkPg St06o+DCyrkug2inTzumTUd/t9ssNDn/iVV3LDtAni9cuUZocuQ5h35jlmjJOcWK YsOP6PtUlSJFLXWm1hDqrqhJaFinmSVokX9cShikUjlYxMRWJlse+Y+qULqVEE4E R91w2UKfAmMwetdyXAYcSu6gVjVxJ9g/aKfN3CfsC3ZWFrZiwdxn82K8/WZ4W6ff CTgSB1ATOAoWOpPlDk3A6mlWWzw27HgERSdJFuLbfdjfpJeqRKUlNIy369TeSQmn rf5cenANO0XWcA== =1O4C -----END PGP SIGNATURE----- --=-=-=--