Re: Tramp with global-auto-revert-mode.

[Kai Grossjohann]

David Kastrup <address@hidden> writes:

> Kai Grossjohann <address@hidden> writes:
>
>> David Kastrup <address@hidden> writes:
>> 
>> > Uh, much too complicated.
>> 
>> I'm afraid I don't understand you: Do you mean that just the last
>> step is too complicated, or that the whole procedure that I described
>> is too complicated?
>
> The whole procedure.

Okay.  I agree.  Though our ideas of simplicity are different -- I
was thinking of using multiple connection buffers.

>> At some point, I thought I understood what you were suggesting, but
>> now I'm not sure anymore.
>> 
>> Let me try to describe my understanding with less detail, then please
>> tell me if I got it at least at this level.
>> 
>>     Whenever Tramp is invoked, it looks to see if the connection
>>     buffer is busy.  If it is, it knows that Tramp is interrupting
>>     itself, so to speak.
>> 
>>     If this is the case (Tramp is interrupting itself), Tramp "takes
>>     over" the command in progress, fetches all output from it and
>>     stashes it someplace safe.
>
> Look, you are talking all the time about "Tramp" as if it was a
> sentient being.  It isn't.

It must be!  It even changed names multiple times, this tells us it
knows what it likes.

> "Tramp" consists of two entirely different pieces: the user level
> routines (of which several can be running at once in different
> "threads" or Emacs' equivalence to it) and the filter routine.  Those
> are basically independent from each other.

What is a filter routine?  If you are talking about process filters,
in the sense of set-process-filter, then there are no filter routines
in Tramp.

Are you suggesting to change Tramp such that there is a filter
routine?

[time passes]  Oh, I see that Michael added a process filter in one
part of Tramp, to support async shell commands.

> In order avoid unnecessary lockup in process-send-string, and
> problems with identifying responses and input, we might not just
> indiscriminately call process-send-string when there are already
> outstanding commands.

Yes.

> Ok, here is what the filter routine does when it is called: it
> collects the stuff from the output until it has a completely reply to
> the currently sent command available.  If it has, it takes the
> request and marks it as completed (tacking the results to the
> request).
>
> [Entry point for getting a command on the way:]
> It then takes a look whether there are still outstanding commands in
> the queue.  If there are, it takes the next one from the queue and
> sends it through, marking it as being in progress.
>
> That's all.  The filter routine never changes, it does just that.
> There is only one filter routine at work at most at any time.
>
> Now for the user level stuff: it knows it needs to get commands
> through.  So it makes a request data structure and tacks it to the end
> of the current queue (or, if the command is particularly urgent, like
> when we are doing autorevert checking, to the _front_ of the current
> queue) and then calls accept-process-output on the process repeatedly
> until the command finally is marked as being processed.  Then it
> takes the results and returns.
>
> That is all.

Okay, this is much clearer.

Kai