From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kai Grossjohann Newsgroups: gmane.emacs.help Subject: Re: Setting gdb to use eshell buffer Date: Tue, 03 Feb 2004 09:26:58 +0100 Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Message-ID: <877jz46019.fsf@emptyhost.emptydomain.de> References: <878ylb2o8a.fsf@emptyhost.emptydomain.de> <40159F4E.8000703@yahoo.com> <87ektfswns.fsf@emptyhost.emptydomain.de> <401ED323.9080906@yahoo.com> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1075797215 938 80.91.224.253 (3 Feb 2004 08:33:35 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 3 Feb 2004 08:33:35 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Feb 03 09:33:28 2004 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1Anvzs-0002SA-00 for ; Tue, 03 Feb 2004 09:33:28 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AnvyK-0007w3-26 for geh-help-gnu-emacs@m.gmane.org; Tue, 03 Feb 2004 03:31:52 -0500 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!fu-berlin.de!uni-berlin.de!213-203-244-156.kunde.vdserver.DE!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 37 Original-NNTP-Posting-Host: 213-203-244-156.kunde.vdserver.de (213.203.244.156) Original-X-Trace: news.uni-berlin.de 1075796800 32552515 213.203.244.156 ([73968] 10430) User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.2 (gnu/linux) Cancel-Lock: sha1:VDP95hZd7/mIKJSb9aOBt0R7hBc= Original-Xref: shelby.stanford.edu gnu.emacs.help:120650 Original-To: help-gnu-emacs@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.help:16598 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:16598 Kevin Rodgers writes: > Kai Grossjohann wrote: > > > > Or one could install a process filter that fishes things from the > > *tramp/foo* buffer and copies them into the *compilation* buffer as > > they arrive. But in that case, we need to prohibit users from > > invoking Tramp in the meantime, as the *tramp/foo* buffer is already > > busy. > > Isn't that necessary anyway? Because otherwise, the current > implementation would have other Tramp data interspersed with the compile > command's output in the *tramp/foo* buffer. Well, my original plan was to allow multiple connections. Then each connection could be dedicated to a single compilation, until that compilation is finished. If two (remote) processes are writing to the same *tramp/foo* buffer, it is nearly impossible to tell the chunks apart later. At least I haven't found a way to do that. But if there was a way, multiplexing a single *tramp/foo* buffer might be the way to go. But you're right anyway: we need a way to copy the output from the remote end from the *tramp/foo* buffer to the *compilation* buffer, as that output arrives, and we need to do that in the background. This means that process filters are the easiest way. And if I want to reuse the same *tramp/foo* buffer for multiple compilations (which is a good idea to avoid connection setup overhead), then it won't work to just name the buffer the *compilation* buffer... > Would it be feasible for the Tramp compilation function to install the > process filter and arrange for it to be uninstalled when its done? Sure. set-process-filter will be my friend. Kai