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: Sat, 31 Jan 2004 21:14:31 +0100 Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Message-ID: <87ektfswns.fsf@emptyhost.emptydomain.de> References: <878ylb2o8a.fsf@emptyhost.emptydomain.de> <40159F4E.8000703@yahoo.com> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1075580244 28403 80.91.224.253 (31 Jan 2004 20:17:24 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 31 Jan 2004 20:17:24 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat Jan 31 21:17:20 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 1An1YO-0005Es-00 for ; Sat, 31 Jan 2004 21:17:20 +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 1An1Wv-0001Se-Bi for geh-help-gnu-emacs@m.gmane.org; Sat, 31 Jan 2004 15:15:49 -0500 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!news.tele.dk!news.tele.dk!small.news.tele.dk!fu-berlin.de!uni-berlin.de!213-203-244-156.kunde.vdserver.DE!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 56 Original-NNTP-Posting-Host: 213-203-244-156.kunde.vdserver.de (213.203.244.156) Original-X-Trace: news.uni-berlin.de 1075580064 29451163 213.203.244.156 ([73968] 10430) User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.2 (gnu/linux) Cancel-Lock: sha1:JuXhLlVXsG+1F0haykEed8sDzpA= Original-Xref: shelby.stanford.edu gnu.emacs.help:120595 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:16542 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:16542 Kevin Rodgers writes: > Kai Grossjohann wrote: > >> ncohen@ucsd.edu writes: >>>Hi I'm using tramp to successfully transparently edit remote files >>>however I also want to compile and debug them from inside emacs. >>>How do I do this? >> With difficulty :-/ >> Tramp comes with a file tramp-util.el which contains a function that >> allows you to do remote compiles. It is, however, a fake, because it >> doesn't show any output until the remote compile is finished. (M-x >> compile RET shows you output as it is arriving.) And what's more, >> Emacs is frozen while it is waiting for the compile to finish. > > From that, I infer that Tramp has the connection write its output to a > local temporary file that it then inserts into a compilation buffer. If > that's the case, why can't the compilation buffer be set up with a process > that tail's the temp file as its written? Remember that Tramp uses a shell connection, the *tramp/foo* buffer, for most of its stuff. (For all of it, except file transfer in the case of out-of-band methods.) The Tramp compilation function sends the compile command to the remote host, waits for the next shell prompt to appear, then extracts what's in *tramp/foo* and copies it to another buffer which it calls a *compilation* buffer. One *could* temporarily rename the *tramp/foo* buffer to *compilation* and show it to the user, then when the compilation is finished, revert the renaming and do the copying thing. Down that path lies madness, though. 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. >> I'm thinking about extending Tramp to allow background processes. I >> think that Tramp needs to open multiple connections to the remote host >> to do that. (If somebody has other ideas, please speak up.) And if >> you open multiple connections to a host, then password caching becomes >> interesting. And password caching is potentially very dangerous. >> Also, it would make sense to reuse connections, instead of opening a >> new connection whenever you issue a new compile command. > > I don't know. If caching passwords is so dangerous, maybe it is worth > the overhead to establish a new connection for each background command. Hm? That means that the poor user will have to type their password for every background command... (In the case of multi-hop methods, multiple passwords.) Kai