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

[Kai Grossjohann]

address@hidden (Kim F. Storm) writes:

> How does it know where the output from the previous operation ends
> (or have arrived at all), i.e. how does it know when the output to its
> own command starts?

I think that David is suggesting that the timer does not start its
own command until the command-in-process is finished.  So it goes
like this:

- User invokes Tramp in some manner.

- Tramp sends a command to the remote host and enters a loop calling
  accept-process-output until the command is complete.  (Tramp knows
  to look for a shell prompt to see that the command is complete.)

- This loop is interrupted by a timer.  The timer sees that such a
  loop is in progress already.

- The timer enters its own accept-process-output loop, fetching
  output from the unknown command until the command completes (shell
  prompt arrives).  It stashes the output away someplace safe.

- Now the timer is free to do its own thing: it sends a command to
  the remote end, uses the accept-process-output loop to fetch the
  result, is happy.

- Just before returning, the timer fetches the output from the safe
  place and inserts it into the connection buffer.  Then the timer
  sends a no-op command to the remote end (but does *not* invoke
  accept-process-output) and returns.

- This is the point in time where the "master" Emacs process gets to
  do something.  It's still inside accept-process-output.  The no-op
  command sent by the timer produces output (a shell prompt) which
  the now-awakened accept-process-output is happy to receive, and it
  wakes up.

- The master accept-process-output loop sees nothing amiss and just
  blissfully processes the buffer contents as if nothing strange
  happened.

I hope I got that right.

It seems rather fragile to me.

Kai