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

[Kai Grossjohann <kai.grossjohann@gmx.net>]

David Kastrup <dak@gnu.org> writes:

> Kai Grossjohann <kai.grossjohann@gmx.net> writes:
>
>> David Kastrup <dak@gnu.org> writes:
>> 
>> > Kai Grossjohann <kai.grossjohann@gmx.net> writes:
>> >
>> >> David Kastrup <dak@gnu.org> 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.
>
> Those have to be set up and initialized.  You know that Tramp
> initialization takes a _lot_ of time.  If we have some timer-related
> events, it is likely that we will get an indefinite stack of sessions
> all occupied with initializing a connection.

I was thinking of letting the additional connection buffer stay
around.  I agree, however, that bootstrapping is somewhat difficult:
how do I make it so that the second buffer appears quickly enough for
auto-revert to be of some use...

>> > "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.
>
> Oh, I see.  Well, it doesn't matter, strictly speaking.  Whoever calls
> accept-process-output should feel qualified, when being woken up, to
> do the work of the non-existent process-filter,

That work is to wait for the next shell prompt.  If it isn't there,
call accept-process-output again.

> and if after that its own task has not been finished (or even
> started), call accept-process-output again.

Yes.

Kai