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: Sun, 16 May 2004 16:11:18 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <86brkoihrt.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> <86wu3d7jel.fsf@slowfox.dyndns.org> <86ekpl61qm.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 1084716813 5286 80.91.224.253 (16 May 2004 14:13:33 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 16 May 2004 14:13:33 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sun May 16 16:13:26 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 1BPMOM-0003RT-00 for ; Sun, 16 May 2004 16:13:26 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BPMOL-0004Dv-00 for ; Sun, 16 May 2004 16:13:26 +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 1BPMO1-000480-Kt for emacs-devel@quimby.gnus.org; Sun, 16 May 2004 10:13:06 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BPMNL-0003a0-1h for emacs-devel@gnu.org; Sun, 16 May 2004 10:12:23 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BPMMK-0002EW-B3 for emacs-devel@gnu.org; Sun, 16 May 2004 10:11:54 -0400 Original-Received: from [213.165.64.20] (helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.34) id 1BPMMJ-0002CB-BQ for emacs-devel@gnu.org; Sun, 16 May 2004 10:11:19 -0400 Original-Received: (qmail 10426 invoked by uid 65534); 16 May 2004 14:11:18 -0000 Original-Received: from pD951F40E.dip.t-dialin.net (EHLO slowfox.dyndns.org) (217.81.244.14) by mail.gmx.net (mp017) with SMTP; 16 May 2004 16:11:18 +0200 X-Authenticated: #361006 Original-Received: by slowfox.dyndns.org (Postfix, from userid 1001) id 79DF941E7; Sun, 16 May 2004 16:11:18 +0200 (CEST) Original-To: David Kastrup In-Reply-To: (David Kastrup's message of "15 May 2004 20:18:13 +0200") User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (berkeley-unix) 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:23536 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:23536 David Kastrup writes: > Kai Grossjohann writes: > >> David Kastrup writes: >> >> > Kai Grossjohann writes: >> > >> >> 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? >> > >> > 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