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#45117: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer Date: Thu, 10 Dec 2020 21:16:00 +0000 Message-ID: <878sa51hwv.fsf@gmail.com> References: <87h7ow4j4o.fsf@gmail.com> <83mtyo71dh.fsf@gnu.org> <877dps47ge.fsf@gmail.com> <83360g6xlt.fsf@gnu.org> <87im9b2pds.fsf@gmail.com> <83k0tr5700.fsf@gnu.org> <87360d3dud.fsf@gmail.com> <83eejx4rd6.fsf@gnu.org> <87r1nx1vtd.fsf@gmail.com> <87mtyl1v6y.fsf@gmail.com> <87h7ot1ona.fsf@gmail.com> <87czzh1kv8.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="10131"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: 45117@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Dec 10 22:17:21 2020 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 1knTJR-0002X2-Ol for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 10 Dec 2020 22:17:21 +0100 Original-Received: from localhost ([::1]:39750 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1knTJQ-00049e-K6 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 10 Dec 2020 16:17:20 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52012) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1knTJ9-00046l-QH for bug-gnu-emacs@gnu.org; Thu, 10 Dec 2020 16:17:07 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56139) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1knTJ8-0005tv-9L for bug-gnu-emacs@gnu.org; Thu, 10 Dec 2020 16:17:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1knTJ8-0002xm-47 for bug-gnu-emacs@gnu.org; Thu, 10 Dec 2020 16:17: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: Thu, 10 Dec 2020 21:17:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45117 X-GNU-PR-Package: emacs Original-Received: via spool by 45117-submit@debbugs.gnu.org id=B45117.16076349769215 (code B ref 45117); Thu, 10 Dec 2020 21:17:02 +0000 Original-Received: (at 45117) by debbugs.gnu.org; 10 Dec 2020 21:16:16 +0000 Original-Received: from localhost ([127.0.0.1]:39452 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knTIN-0002N6-Ga for submit@debbugs.gnu.org; Thu, 10 Dec 2020 16:16:16 -0500 Original-Received: from mail-wr1-f48.google.com ([209.85.221.48]:46789) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1knTII-0002Ew-1T for 45117@debbugs.gnu.org; Thu, 10 Dec 2020 16:16:13 -0500 Original-Received: by mail-wr1-f48.google.com with SMTP id l9so6927783wrt.13 for <45117@debbugs.gnu.org>; Thu, 10 Dec 2020 13:16:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=bZyzODt8CYUt/roB3Vhonh2Q9ITu51FaI5PiZTyhh2Y=; b=B8yZGTVNniAAKryo+/v2oXvvyAAdBKMk6WJOmZxppGUrJNUPpUPxHPiHBhW6Sp16+e ozV2pcHJk2c4i1J0FSgRU95GDLnPGL79CKeBPnw5+sPMRmpzMd3Qo/kwOcg82x0mNjbb 7MP7MtDgu2mj5VVdl0gs+k7ndzk5XlSMqln4nbTg1B1uypbNcC9hxodjVncBC8eF1vlF 5Gi+j9TA4kagAS7L9cvxmrRqVCjZm88TXPZF9pesQs1jLneggcF41aV8QgP9kvdp2ZIP 82eZPyVZKk4PduM5Lx0modXcz4rbrGYIHmJen2N06AaZa1QNM3rjNgnhqhFhxclO3bjT fJwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=bZyzODt8CYUt/roB3Vhonh2Q9ITu51FaI5PiZTyhh2Y=; b=TIQrQpMwczLsYBDT+0I6npZpulqlSpgYtuDPb4beyAEtP1H3pR0+BlKARs7NlGzawK bqx8ZWZekgXVACFfkFMFJcSkrkB5M21QT2TABT4dSO/EmFfohVwkudbhHYLPCt/J3bFx w6bH7pVGqJN1wUWBflD7ZeIn9n+cDC7L5opT9wr09Wu9gSrldzeKmq/7g12js8vDVqdR 3imecKxSOU494e7BHWZUm75qeUQOv3NtKWFAbW9lGXNNq+yMzG2qgx7wfzvsGYhDVopt KBk7A9g1uDwM/D5JNGJNefIyZ84N8DgHa6siwb7Zdk8JQZUwMwfT6E7joFLPGeqpZwSb U92w== X-Gm-Message-State: AOAM53398cUlNjyS8FKIs9ah5co8iooNLsHv8VtlSXcxKQBMhRWFAF2F yVaZn0mkt07Rw36fHGJ4gtl6KUO5wpI= X-Google-Smtp-Source: ABdhPJxZggHNRQWNmdbFgohM0D27LDcIevs+drKRqgVGmN0jIUEoclxIsorNi47B2AT0nbo2evny4Q== X-Received: by 2002:adf:a29d:: with SMTP id s29mr10248504wra.272.1607634963889; Thu, 10 Dec 2020 13:16:03 -0800 (PST) Original-Received: from krug ([87.196.174.9]) by smtp.gmail.com with ESMTPSA id b73sm11800404wmb.0.2020.12.10.13.16.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Dec 2020 13:16:03 -0800 (PST) In-Reply-To: (Stefan Monnier's message of "Thu, 10 Dec 2020 15:43:16 -0500") 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" Xref: news.gmane.io gmane.emacs.bugs:195708 Archived-At: Stefan Monnier writes: >>> No, I was no presuming such a simple model, actually. I was really >>> thinking about "send data to the LSP server then get some answer >>> a second or more later". >> Right, so in LSP it's perfectly possible to send three requests in a >> row, say reqX, reqY and reqZ and get three replies in a completely >> different order repZ, repX, repY. How to you match each reply to each >> request? > > I assume there's some "request-id" mechanism. Not sure what this has to > do with this discussion, OTOH. Right, a request-id mechanism. The request must be registered atomically with process_send_string. If you interrupt in between, you have inconsistent requests (either registered request-id's for which no actual request was fired, or requests which were fired for which no request-id's were registered). Client code can detect/prevent these interruptions, but it's clumsy. And may cost the dev many hours to understand what is up. Shouldn't be default IMO. >> process_send_string may send things in "bunches", I read in the >> docstring, but it will not (and should not) be interrupted. > > Indeed, I believe it should not be aborted in the middle by > `while-no-input` (it would be a bug, because the `process-send-string` > API doesn't offer any way to know what has been or hasn't been sent in > that case). Agree. >> But that is not always so. And I think it's too eager of ElDoc to try >> to do that so early and so brutally. It's better to leave it to the >> callback handlers, which we have now. That's a much safer spot to >> know if the answer we just got still makes sense. Or if we're in >> a hurry, we let the backend know asap. > > You might be right: the result of the current request sent to the LSP > could still be useful for the next eldoc-idle-time cycle, indeed. Yes, it's only an heuristic. >>> The contract is different for timer functions than it is for eldoc >>> functions, yes. This is because the expectation is that eldoc functions >>> may run for a non-negligible amount of time. >> Why do you have that expectation? Any particular example in the wild? > Good question. :-) >> It was, after all, the status quo after you changed it for 27.1. >> Perhaps you had a rationale? > > I probably did, but ... can't remember and wasn't clever enough to write > it in the commit message :-( > Maybe to accommodate those backends which needed async operation but had > to live within the confines of the previously limited eldoc API? Likely, yes. But which one of those were the "blocking" type? Because even with the limited API, SLY/SLIME were just calling eldoc-message from the process filter. Which is equivalent to what we have now in terms of sync. In fact, to keep backward compatibility, I haven't touched this part of SLY at all. Anyway, you must have done it for some other slow synchronous, wait-for-the-retval backend. That hypothetical backend will hurt if we take back the while-no-input. OTOH that hypothetical backend can now upgrade to a much better API. > Maybe the maintainer of eldoc.el will prefer to undo this change, > then ;-) ? Who's that? ;-) But OK, eldoc.el is now distributable independently so we have good defense against this. Jo=C3=A3o