bug#45117: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> 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.

> 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).

>> Indeed, we bind inhibit-quit there because when the users hit C-g they
>> presumably have no idea whether a timer or process filter happens to be
>> running right now, so they don't actually mean "stop this timer" but
>> something entirely different (such as run the command `keyboard-quit`).
> I see, and you you think it is different for "input something", because
> that in ElDoc, would in principle invalidate the context of the
> documentation request.

Indeed for eldoc we know that if there is user input, the current
request can be dropped on the floor because its result shouldn't be
displayed anyway.

In contrast in the general case of timers we don't know whether
user-input affects the usefulness of running the timer.

> 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.

>> 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?

Maybe the maintainer of eldoc.el will prefer to undo this change,
then ;-) ?


        Stefan