From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 15 06:55:01 2022 Received: (at submit) by debbugs.gnu.org; 15 Dec 2022 11:55:01 +0000 Received: from localhost ([127.0.0.1]:42869 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p5mpI-0002aS-Vp for submit@debbugs.gnu.org; Thu, 15 Dec 2022 06:55:01 -0500 Received: from lists.gnu.org ([209.51.188.17]:54668) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p5mpG-0002aM-V4 for submit@debbugs.gnu.org; Thu, 15 Dec 2022 06:54:59 -0500 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 1p5mpG-0007Ic-L6 for bug-gnu-emacs@gnu.org; Thu, 15 Dec 2022 06:54:58 -0500 Received: from mail-wr1-x42f.google.com ([2a00:1450:4864:20::42f]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p5mpC-0006hh-0b; Thu, 15 Dec 2022 06:54:58 -0500 Received: by mail-wr1-x42f.google.com with SMTP id o5so2793345wrm.1; Thu, 15 Dec 2022 03:54:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:to :from:from:to:cc:subject:date:message-id:reply-to; bh=v7Sa3LfqHTd6Mcwi1lJHo56h8kUWjY8uHwUR+zcuDN0=; b=AAX188XLwaKJOYdkudo2TMMWt9AE86KUDQqWR+IFuNSlHrVGDyUEwcu0jl95KX1iHE +D8rjwWoQrTGyAr5hrgEB7pmbBYFZiYDyb/sV2pkHLQfneXqrM828BGAA6qADMfNK7i4 h5yweWGkQ8tMnHcCc9Ui+Zzc1dY+zdB8pdXFORZUkPwm9VKqVCIQsHYUE7EOonjQFg/a wPg33hBsxZXkcwD+El0n5+hUp3KxEWnWM6UtKwpKnorOc7o5o5+Ns3EmosGx04LXBbap RKxAsgUtgTImYR4ff9t36Nnw64vDOmutvb3+WT7WpPhBn99JeZaspHsK+Vy4GYGtTeyX d1Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=v7Sa3LfqHTd6Mcwi1lJHo56h8kUWjY8uHwUR+zcuDN0=; b=e3Y8QXM7pAYU+gLATRIenqcxoKgwtjyF24gLsfR5r4fG7LdRlWA/uu2AKY1JxvAERe KQyEeuCmT/C2doPrt7Fe0U+kTxkj5C1IiO9M29EmT0bPpHpxLgeJFw6RYQznFexQV2bF 6/dmrYKtLu515biTWSiEHdkb4qK1PO7g1J8+mOY1B2EGa9g7+ZyWneOplORQzFQo0OSm KXMj7ry20FupbuPLInO4Fn3SbVDJt0NqLk1qo0c/IyElh+/ODoksQzegvtAZr2JnyOKM o73owds1/Nc0Uyp3NjqkPcEA2KExatJndhLZ8sktQQUZuoFgtRMyaKOKBbqx88yunS/C OO8A== X-Gm-Message-State: AFqh2kpx9RyAYT6SBI7cE+w/Xiu1Gs+JtfkCFe0c5ALT79768M3SOyXg dW9Rv+POErKeON+mrqTzmE992VjgsOg= X-Google-Smtp-Source: AMrXdXutIb0BiadVNwcqKcmKOn/bp2+TMV0k/wXPBLHLSV4crNRzv/gpFko3HahQ2nCvQ85apLdzYQ== X-Received: by 2002:a5d:58f8:0:b0:256:1d9b:bd4b with SMTP id f24-20020a5d58f8000000b002561d9bbd4bmr4492182wrd.55.1671105291224; Thu, 15 Dec 2022 03:54:51 -0800 (PST) Received: from krug ([87.196.73.63]) by smtp.gmail.com with ESMTPSA id f9-20020a05600c154900b003b49bd61b19sm2483462wmg.15.2022.12.15.03.54.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Dec 2022 03:54:50 -0800 (PST) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= To: bug-gnu-emacs@gnu.org, eliz@gnu.org Subject: 29.0.60; Eglot loses messages from gopls Date: Thu, 15 Dec 2022 11:56:15 +0000 Message-ID: <87pmckg9sw.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2a00:1450:4864:20::42f; envelope-from=joaotavora@gmail.com; helo=mail-wr1-x42f.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) [Eli, I have CC'ed you directly because this bug concerns a technique to avoid recursive process filters, which seems like an area you are expert in.] Hi,=20 In some situations, Eglot is losing some messages from the Go language server, 'gopls'. The problem has been reproduced and identified. For context, this started in: * https://github.com/joaotavora/eglot/issues/587#issuecomment-1221072833 * https://github.com/golang/go/issues/54559 (In the former link, there are reports of what seem to be other problems. The reports are missing clear reproduction recipes, so they may not be the same problem I'm about to describe.) Reproduction: Ensure go-mode is installed from https://melpa.org/#/go-mode $ go install golang.org/x/tools/gopls@latest $ git clone git clone https://github.com/google/nftables $ emacs -Q -f package-initialize nftables/nftables_test.go M-x eglot The last step will connect to the server, exchange some messages. It will not block Emacs, but the Eglot session will be completely non-functional. Analysis: Many essential JSONRPC messages have not been exchanged, they have been lost. The bytes of the lost messages from the gopls side can be seen in the process buffer (M-x list-processes, then click the link to the hidden process buffer). The problem happens in jsonrpc.el's jsonrpc--process-filter. The code does not expect this function to be called recursively, but that can happen if the client code invoked by its jsonrpc--connection-receive callee eventually sends a follow-up message to the server. This is a common scenario, especially during LSP initialiation. It has been working fine for a number of years and a large number of servers. However: * if that follow-up message is large enough (this is why the largish nftables_test.go file is needed) AND * the server has already sent us some output with just the right (wrong) timing. then the process-send-string call that is eventually reached will in fact cause more output to arrive from the process and a recursive invocation of the process filter. Resolution: I've looked at a number of ways to solve this problem, from avoiding the follow up message in Eglot's side to different techniques on the jsonrpc side. None of them are as satisfactory as the patch after my sig, which simply re-schedules the would-be recursive call to re-run from within a timer stack as soon as possible. The only problem I can envision with this approach would be if multiple recursive calls are launched from the same jsonrpc--connection-receive stack frame and would somehow not be executed in the correct order. That doesn't seem to be a problem after some experiments like (progn (run-at-time 0 nil #'insert "a") (run-at-time 0 nil #'insert "b") (run-at-time 0 nil #'insert "c")) which inserts the predicatbly sane "abc". If this in-order execution is somehow not guaranteed, there is the alternate more complex technique of inserting the output into the process buffer immediately, and schedule a single processing call thereafter. I will install the following patch soon unless someone objects to this approach. Jo=C3=A3o diff --git a/lisp/jsonrpc.el b/lisp/jsonrpc.el index 90833e1c1d..76bbf28138 100644 --- a/lisp/jsonrpc.el +++ b/lisp/jsonrpc.el @@ -548,11 +548,27 @@ jsonrpc--process-sentinel (delete-process proc) (funcall (jsonrpc--on-shutdown connection) connection))))) =20 -(defun jsonrpc--process-filter (proc string) +(defvar jsonrpc--in-process-filter nil + "Non-nil if inside `jsonrpc--process-filter'.") + +(cl-defun jsonrpc--process-filter (proc string) "Called when new data STRING has arrived for PROC." + (when jsonrpc--in-process-filter + ;; Problematic recursive process filters may happen if + ;; `jsonrpc--connection-receive', called by us, eventually calls + ;; client code which calls `process-send-string' (which see) to, + ;; say send a follow-up message. If that happens to writes enough + ;; bytes for additional output to be received, we have a problem. + ;; + ;; In that case, remove recursiveness by re-scheduling ourselves to + ;; run from within a timer as soon as possible. + + (run-at-time 0 nil #'jsonrpc--process-filter proc string) + (cl-return-from jsonrpc--process-filter)) (when (buffer-live-p (process-buffer proc)) (with-current-buffer (process-buffer proc) (let* ((inhibit-read-only t) + (jsonrpc--in-process-filter t) (connection (process-get proc 'jsonrpc-connection)) (expected-bytes (jsonrpc--expected-bytes connection))) ;; Insert the text, advancing the process marker. From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 16 03:55:51 2022 Received: (at 60088) by debbugs.gnu.org; 16 Dec 2022 08:55:51 +0000 Received: from localhost ([127.0.0.1]:48050 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p66VS-00068m-Gi for submit@debbugs.gnu.org; Fri, 16 Dec 2022 03:55:51 -0500 Received: from mail-oa1-f45.google.com ([209.85.160.45]:41732) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p66VQ-00068W-HY for 60088@debbugs.gnu.org; Fri, 16 Dec 2022 03:55:49 -0500 Received: by mail-oa1-f45.google.com with SMTP id 586e51a60fabf-1441d7d40c6so2481617fac.8 for <60088@debbugs.gnu.org>; Fri, 16 Dec 2022 00:55:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=u5XldW6zxlYwjfmRtReLZpZefnwWRE+72qctSIml2hw=; b=WGDjPeSK5HAhqmX7Gdr9AbALHbAwpzasx/h4WCaRp+O5p1kWmGt8S2hjIoKJTv603k PUM2doHZkSVRHaCrieRMl4T58wHfvTVsCJZtgi6FdfIhak9xM6+KpBCw4JnmXeFU617x 7461MxON9j2PkZlA4qcFiT/KQ9/XuNlz9VsEl/Feg2x4VaxLA/oZbCO2wbBplkCcq2eb pVgJqQJoRrHZFYSsV30qE5RdWjgvgQKyD1H6UbWAVG81TtaLMCVgAKzMze7craubZa7u wB1hCodtMZRD7Zj/FUzDmCZtRwg3IlmxhJFbSHdPzfTfexOLnAZeTYVisHUJCoUCYOQV jTmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=u5XldW6zxlYwjfmRtReLZpZefnwWRE+72qctSIml2hw=; b=dfP3OG6MtzAEMqbWywxo4tVQ86r8ux3fAhE42KIlcf4fZn3CbFKhUf7Cx4MlR8UuF8 7RawGj9+DuYve8LYA8YdAfCd+xTrOut6ziUVBkHBhOptFyKHgjBjx750yg2wV+J3UIXz 25pAq4eIiYjNOULuHeaUWiz01mA4S+FWYYTImu10oMT77PUsbiwdC1WwAaMjhpKRJAG3 g6wz1fblSYfoV+ZybW4UFluZnSltcgBasTNNL+C+sEIgLo78bO7J0HDI8NveXgQUIiUG Ik/Jssa9lShpFnqFDz6JYjfci804tDR3iuNjxOBf6kM2oP2EM3LJb+eUZ+JYw8wqVZvS mWqA== X-Gm-Message-State: AFqh2kr/T0Pb/OMpoa2vNE64abxr/g1oEY5qAb2dOx8d5xS8lX3uTRB9 R5pXToPyS03tHsMGVh9GrE0R2VtkaDw4VYxD3ub8sw2t X-Google-Smtp-Source: AMrXdXsuGcrzc9FAkVgoJ1zwCsDQC4ERHrYkA8CTEGVJs1655bwIrWI26UTf2XzLRq1dqyACbyZDzlQdqDTRv834tII= X-Received: by 2002:a05:6870:3116:b0:143:7889:c525 with SMTP id v22-20020a056870311600b001437889c525mr363266oaa.171.1671180942529; Fri, 16 Dec 2022 00:55:42 -0800 (PST) MIME-Version: 1.0 References: <87pmckg9sw.fsf@gmail.com> In-Reply-To: <87pmckg9sw.fsf@gmail.com> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Fri, 16 Dec 2022 08:56:56 +0000 Message-ID: Subject: Re: bug#60088: 29.0.60; Eglot loses messages from gopls To: 60088@debbugs.gnu.org, eliz@gnu.org Content-Type: multipart/alternative; boundary="0000000000006f591e05efee22de" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 60088 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000006f591e05efee22de Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I've now pushed the patch/bugfix to emacs-29 and bumped version of jsonrpc.el so we should get a new GNU ELPA package soon. GNU ELPA Eglot users should wait for the package to be bumped too. Jo=C3=A3o On Thu, Dec 15, 2022 at 11:55 AM Jo=C3=A3o T=C3=A1vora wrote: > [Eli, I have CC'ed you directly because this bug concerns a technique to > avoid recursive process filters, which seems like an area you are expert > in.] > > Hi, > > In some situations, Eglot is losing some messages from the Go language > server, 'gopls'. The problem has been reproduced and identified. > > For context, this started in: > > * https://github.com/joaotavora/eglot/issues/587#issuecomment-1221072833 > * https://github.com/golang/go/issues/54559 > > (In the former link, there are reports of what seem to be other > problems. The reports are missing clear reproduction recipes, so they > may not be the same problem I'm about to describe.) > > Reproduction: > > Ensure go-mode is installed from https://melpa.org/#/go-mode > $ go install golang.org/x/tools/gopls@latest > $ git clone git clone https://github.com/google/nftables > $ emacs -Q -f package-initialize nftables/nftables_test.go > M-x eglot > > The last step will connect to the server, exchange some messages. It > will not block Emacs, but the Eglot session will be completely > non-functional. > > Analysis: > > Many essential JSONRPC messages have not been exchanged, they have been > lost. The bytes of the lost messages from the gopls side can be seen in > the process buffer (M-x list-processes, then click the link to the > hidden process buffer). > > The problem happens in jsonrpc.el's jsonrpc--process-filter. The code > does not expect this function to be called recursively, but that can > happen if the client code invoked by its jsonrpc--connection-receive > callee eventually sends a follow-up message to the server. This is a > common scenario, especially during LSP initialiation. It has been > working fine for a number of years and a large number of servers. > > However: > > * if that follow-up message is large enough (this is why the largish > nftables_test.go file is needed) AND > > * the server has already sent us some output with just the right (wrong) > timing. > > then the process-send-string call that is eventually reached will in > fact cause more output to arrive from the process and a recursive > invocation of the process filter. > > Resolution: > > I've looked at a number of ways to solve this problem, from avoiding the > follow up message in Eglot's side to different techniques on the jsonrpc > side. None of them are as satisfactory as the patch after my sig, which > simply re-schedules the would-be recursive call to re-run from within a > timer stack as soon as possible. > > The only problem I can envision with this approach would be if multiple > recursive calls are launched from the same jsonrpc--connection-receive > stack frame and would somehow not be executed in the correct order. > That doesn't seem to be a problem after some experiments like > > (progn > (run-at-time 0 nil #'insert "a") > (run-at-time 0 nil #'insert "b") > (run-at-time 0 nil #'insert "c")) > > which inserts the predicatbly sane "abc". If this in-order execution is > somehow not guaranteed, there is the alternate more complex technique of > inserting the output into the process buffer immediately, and schedule a > single processing call thereafter. > > I will install the following patch soon unless someone objects to this > approach. > > Jo=C3=A3o > > diff --git a/lisp/jsonrpc.el b/lisp/jsonrpc.el > index 90833e1c1d..76bbf28138 100644 > --- a/lisp/jsonrpc.el > +++ b/lisp/jsonrpc.el > @@ -548,11 +548,27 @@ jsonrpc--process-sentinel > (delete-process proc) > (funcall (jsonrpc--on-shutdown connection) connection))))) > > -(defun jsonrpc--process-filter (proc string) > +(defvar jsonrpc--in-process-filter nil > + "Non-nil if inside `jsonrpc--process-filter'.") > + > +(cl-defun jsonrpc--process-filter (proc string) > "Called when new data STRING has arrived for PROC." > + (when jsonrpc--in-process-filter > + ;; Problematic recursive process filters may happen if > + ;; `jsonrpc--connection-receive', called by us, eventually calls > + ;; client code which calls `process-send-string' (which see) to, > + ;; say send a follow-up message. If that happens to writes enough > + ;; bytes for additional output to be received, we have a problem. > + ;; > + ;; In that case, remove recursiveness by re-scheduling ourselves to > + ;; run from within a timer as soon as possible. > + > + (run-at-time 0 nil #'jsonrpc--process-filter proc string) > + (cl-return-from jsonrpc--process-filter)) > (when (buffer-live-p (process-buffer proc)) > (with-current-buffer (process-buffer proc) > (let* ((inhibit-read-only t) > + (jsonrpc--in-process-filter t) > (connection (process-get proc 'jsonrpc-connection)) > (expected-bytes (jsonrpc--expected-bytes connection))) > ;; Insert the text, advancing the process marker. > > > > > > > > > > > > > --=20 Jo=C3=A3o T=C3=A1vora --0000000000006f591e05efee22de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've now pushed the patch/bugfix to emacs-29 and = bumped
version of jsonrpc.el so we should get a new GNU ELPA pack= age
soon.
=C2=A0
GNU ELPA Eglot user= s should wait for the package to be bumped
too.
Jo=C3=A3o

On Thu, Dec 15, 2022 at 11:55 AM Jo=C3=A3o = T=C3=A1vora <joaotavora@gmail.co= m> wrote:
[Eli, I have CC'ed you directly because this bug concerns a technique = to
avoid recursive process filters, which seems like an area you are expert in.]

Hi,

In some situations, Eglot is losing some messages from the Go language
server, 'gopls'.=C2=A0 The problem has been reproduced and identifi= ed.

For context, this started in:

* https://github.com/joaotavor= a/eglot/issues/587#issuecomment-1221072833
* https://github.com/golang/go/issues/54559

(In the former link, there are reports of what seem to be other
problems.=C2=A0 The reports are missing clear reproduction recipes, so they=
may not be the same problem I'm about to describe.)

Reproduction:

=C2=A0 Ensure go-mode is installed from https://melpa.org/#/go-mode =C2=A0 $ go install golang.org/x/tools/gopls@latest
=C2=A0 $ git clone git clone https://github.com/google/nftables
=C2=A0 $ emacs -Q -f package-initialize nftables/nftables_test.go
=C2=A0 M-x eglot

The last step will connect to the server, exchange some messages.=C2=A0 It<= br> will not block Emacs, but the Eglot session will be completely
non-functional.

Analysis:

Many essential JSONRPC messages have not been exchanged, they have been
lost.=C2=A0 The bytes of the lost messages from the gopls side can be seen = in
the process buffer (M-x list-processes, then click the link to the
hidden process buffer).

The problem happens in jsonrpc.el's jsonrpc--process-filter.=C2=A0 The = code
does not expect this function to be called recursively, but that can
happen if the client code invoked by its jsonrpc--connection-receive
callee eventually sends a follow-up message to the server.=C2=A0 This is a<= br> common scenario, especially during LSP initialiation.=C2=A0 It has been
working fine for a number of years and a large number of servers.

However:

* if that follow-up message is large enough (this is why the largish
=C2=A0 nftables_test.go file is needed) AND

* the server has already sent us some output with just the right (wrong) =C2=A0 timing.

then the process-send-string call that is eventually reached will in
fact cause more output to arrive from the process and a recursive
invocation of the process filter.

Resolution:

I've looked at a number of ways to solve this problem, from avoiding th= e
follow up message in Eglot's side to different techniques on the jsonrp= c
side.=C2=A0 None of them are as satisfactory as the patch after my sig, whi= ch
simply re-schedules the would-be recursive call to re-run from within a
timer stack as soon as possible.

The only problem I can envision with this approach would be if multiple
recursive calls are launched from the same jsonrpc--connection-receive
stack frame and would somehow not be executed in the correct order.
That doesn't seem to be a problem after some experiments like

(progn
=C2=A0 (run-at-time 0 nil #'insert "a")
=C2=A0 (run-at-time 0 nil #'insert "b")
=C2=A0 (run-at-time 0 nil #'insert "c"))

which inserts the predicatbly sane "abc".=C2=A0 If this in-order = execution is
somehow not guaranteed, there is the alternate more complex technique of inserting the output into the process buffer immediately, and schedule a single processing call thereafter.

I will install the following patch soon unless someone objects to this
approach.

Jo=C3=A3o

diff --git a/lisp/jsonrpc.el b/lisp/jsonrpc.el
index 90833e1c1d..76bbf28138 100644
--- a/lisp/jsonrpc.el
+++ b/lisp/jsonrpc.el
@@ -548,11 +548,27 @@ jsonrpc--process-sentinel
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(delete-process proc)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(funcall (jsonrpc--on-shutdown connection= ) connection)))))

-(defun jsonrpc--process-filter (proc string)
+(defvar jsonrpc--in-process-filter nil
+=C2=A0 "Non-nil if inside `jsonrpc--process-filter'.")
+
+(cl-defun jsonrpc--process-filter (proc string)
=C2=A0 =C2=A0"Called when new data STRING has arrived for PROC."<= br> +=C2=A0 (when jsonrpc--in-process-filter
+=C2=A0 =C2=A0 ;; Problematic recursive process filters may happen if
+=C2=A0 =C2=A0 ;; `jsonrpc--connection-receive', called by us, eventual= ly calls
+=C2=A0 =C2=A0 ;; client code which calls `process-send-string' (which = see) to,
+=C2=A0 =C2=A0 ;; say send a follow-up message.=C2=A0 If that happens to wr= ites enough
+=C2=A0 =C2=A0 ;; bytes for additional output to be received, we have a pro= blem.
+=C2=A0 =C2=A0 ;;
+=C2=A0 =C2=A0 ;; In that case, remove recursiveness by re-scheduling ourse= lves to
+=C2=A0 =C2=A0 ;; run from within a timer as soon as possible.
+
+=C2=A0 =C2=A0 (run-at-time 0 nil #'jsonrpc--process-filter proc string= )
+=C2=A0 =C2=A0 (cl-return-from jsonrpc--process-filter))
=C2=A0 =C2=A0(when (buffer-live-p (process-buffer proc))
=C2=A0 =C2=A0 =C2=A0(with-current-buffer (process-buffer proc)
=C2=A0 =C2=A0 =C2=A0 =C2=A0(let* ((inhibit-read-only t)
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(jsonrpc--in-process-filte= r t)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (connection (process-get p= roc 'jsonrpc-connection))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (expected-bytes (jsonrpc--= expected-bytes connection)))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; Insert the text, advancing the process= marker.














--
Jo=C3=A3o T=C3=A1vora
--0000000000006f591e05efee22de-- From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 05 19:51:44 2023 Received: (at 60088-done) by debbugs.gnu.org; 5 Sep 2023 23:51:44 +0000 Received: from localhost ([127.0.0.1]:59879 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qdfpg-0005Qr-7G for submit@debbugs.gnu.org; Tue, 05 Sep 2023 19:51:44 -0400 Received: from mail-lf1-x12d.google.com ([2a00:1450:4864:20::12d]:52685) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qdfpe-0005Qe-0o for 60088-done@debbugs.gnu.org; Tue, 05 Sep 2023 19:51:43 -0400 Received: by mail-lf1-x12d.google.com with SMTP id 2adb3069b0e04-501bd6f7d11so2189449e87.1 for <60088-done@debbugs.gnu.org>; Tue, 05 Sep 2023 16:51:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693957895; x=1694562695; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date :mime-version:references:in-reply-to:from:from:to:cc:subject:date :message-id:reply-to; bh=kwnyKXkK55Vda0q7PSGCmExUiISLeHZ540ldCOkrWOA=; b=QSeczeLVif9eIJHp/G33uIdCS+hHPiX2g9lIitgTkQcfUJmp5vqku5Q4wVieeSXyke n7i/IRfYOFtesto2Z7X/2UyBAB+429qHvMk1i9PZsDb1upuBLLHjPdw1Yo31Yr8xGoVV oJYb8/gkqbO76B2EyrtkXUB0PxfwL5G1FcfGbyGgL/UOe8u9EUHFKiLUbFWWMOlyyCna bNOLq0FVQIgumhO1NHDyu37WYc4iniN6PpGArULOYzmcWGJNXnrn/mvMhlYIZ33eNkUT Hmze1d3onMGhkBNdCNB7ek+UhhnDfXlUaDQUknZIV/WKioZBMB1qcnm7qWa/aKDc/wU8 5qCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693957895; x=1694562695; h=content-transfer-encoding:cc:to:subject:message-id:date :mime-version:references:in-reply-to:from:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=kwnyKXkK55Vda0q7PSGCmExUiISLeHZ540ldCOkrWOA=; b=knWUY+B5r/Z2/Lz9hW+AlhSgHQlK4DF5TUREe74gIcMCb1nqv+KPp7I3o4yUxL5fzN aAo2pNN7gsXsRrisv52lGIMnGK+6q8zmNy3DzSAq3M2dgYwyJeXmMtrMXIzMs0AKLqRz zbLZ/nYSj6eZVRFOCuQlHtr3hfWBMhUT4WPSwMvmR9e75rrteeBmoGX2/pOmv9Fd+uII QyUii3GXjQxQ8G9Z+1jRpKoDqebOhyOyUvfuD2LfL7JP8yk7oIcZCuvizbSaevfz3Otk qIkiIpRrfuRJyOv+kq7Uz8kPgm2Ac2nUxANFqLLB66dDtdexaWyx+zzx6GPcUY6bmgHa CafA== X-Gm-Message-State: AOJu0YybLwchSZm/O/0XunfzeNIywQlAM9Ojx+t6KyqCJZHJjLFPVaYb C2BgzlOSU1MLZb/BBSTFtl2fM15TxcqGXACA6gQ= X-Google-Smtp-Source: AGHT+IHwHTz7QbPHyMyR54FDinTR2mfvRCrpCbNccoijobUJ8OwNv830mfjp3U0COabNaF70xnGxKD4FTNAst9BICEM= X-Received: by 2002:a05:6512:2393:b0:500:b5db:990b with SMTP id c19-20020a056512239300b00500b5db990bmr1032637lfv.47.1693957895263; Tue, 05 Sep 2023 16:51:35 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Tue, 5 Sep 2023 16:51:34 -0700 From: Stefan Kangas In-Reply-To: =?UTF-8?B?PENBTERubTUxWG1qKzAwdUdSPWduT0tHQmtXMDNlX0o4eFppd1dBN1ZiLVFCdnc2?= =?UTF-8?B?azZIZ0BtYWlsLmdtYWlsLmNvbT4gKCJKb8OjbyBUw6F2b3JhIidzIG1lc3NhZ2Ugb2YgIkZyaSwgMTYg?= =?UTF-8?B?RGVjIDIwMjIgMDg6NTY6NTYgKzAwMDAiKQ==?= References: <87pmckg9sw.fsf@gmail.com> MIME-Version: 1.0 Date: Tue, 5 Sep 2023 16:51:34 -0700 Message-ID: Subject: Re: bug#60088: 29.0.60; Eglot loses messages from gopls To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 60088-done Cc: eliz@gnu.org, 60088-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Jo=C3=A3o T=C3=A1vora writes: > I've now pushed the patch/bugfix to emacs-29 and bumped > version of jsonrpc.el so we should get a new GNU ELPA package > soon. I'm therefore closing this bug report. From unknown Tue Jun 17 01:48:00 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 04 Oct 2023 11:24:43 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator