From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kai Grossjohann Newsgroups: gmane.emacs.devel Subject: Re: Tramp with global-auto-revert-mode. Date: Sat, 15 May 2004 18:19:14 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <86wu3d7jel.fsf@slowfox.dyndns.org> References: <200405122254.i4CMsUj29445@raven.dms.auburn.edu> <200405122326.i4CNQk929511@raven.dms.auburn.edu> <200405132324.i4DNOBs14811@raven.dms.auburn.edu> <200405140008.i4E08lb14858@raven.dms.auburn.edu> <871xln4xmc.fsf-monnier+emacs@gnu.org> <87oeorb5pq.fsf@emptyhost.emptydomain.de> <863c62kai6.fsf@slowfox.dyndns.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1084638108 32028 80.91.224.253 (15 May 2004 16:21:48 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 15 May 2004 16:21:48 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sat May 15 18:21:42 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BP1uv-00028a-00 for ; Sat, 15 May 2004 18:21:41 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BP1uv-00066F-00 for ; Sat, 15 May 2004 18:21:41 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BP1tQ-0000ay-Ir for emacs-devel@quimby.gnus.org; Sat, 15 May 2004 12:20:08 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BP1t8-0000aK-8f for emacs-devel@gnu.org; Sat, 15 May 2004 12:19:50 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BP1sc-0000Sy-G9 for emacs-devel@gnu.org; Sat, 15 May 2004 12:19:49 -0400 Original-Received: from [80.91.224.249] (helo=main.gmane.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BP1sc-0000Sn-2G for emacs-devel@gnu.org; Sat, 15 May 2004 12:19:18 -0400 Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BP1sb-0005RW-00 for ; Sat, 15 May 2004 18:19:17 +0200 Original-Received: from pd951f40e.dip.t-dialin.net ([217.81.244.14]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 15 May 2004 18:19:17 +0200 Original-Received: from kai.grossjohann by pd951f40e.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 15 May 2004 18:19:17 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-To: emacs-devel@gnu.org Original-Lines: 57 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd951f40e.dip.t-dialin.net User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (berkeley-unix) Cancel-Lock: sha1:tKQSUD8LvagxK/tU2uJYulccy0g= X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:23484 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:23484 David Kastrup 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