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

[Kai Grossjohann]

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?

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.

    Then it does its own thing.

    Afterwards, it gets the output from the safe place, inserts it
    into the connection buffer, and makes it appear to the
    "interrupted" "master" Tramp as if nothing had happened in the
    meantime.

You were also talking about a queue of commands, which I'm not seeing.
So this would be an indication that I misunderstood you.

(The above does imply a stack of commands, corresponding to
interruptions of interruptions.)

> When output arrives, the currently active filter function will be
> called with it and _all_ accept-process-output calling threads will
> get woken up again.  So they will need to check whether their
> respective work has already been done or aborted by the filter
> routine.

Hm.  If more than one thread of execution will be woken up at the
same time, then surely the above procedure won't work.

> I wrote:
>
>> It seems rather fragile to me.
>
> Same here.  The filter routine just should just mark the last command
> sent to the remote shell as finished, and then see whether any
> job/command is still pending.  If yes, it sends it.

Maybe once I understand your proposal I will understand that it is
less fragile...

Kai