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: Wed, 17 Dec 2003 20:17:25 +0000 Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Message-ID: <878ylb2o8a.fsf@emptyhost.emptydomain.de> References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1071693367 7889 80.91.224.253 (17 Dec 2003 20:36:07 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 17 Dec 2003 20:36:07 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Dec 17 21:36:04 2003 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 1AWiOq-0000hU-00 for ; Wed, 17 Dec 2003 21:36:04 +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 1AWjHm-00067Q-4Y for geh-help-gnu-emacs@m.gmane.org; Wed, 17 Dec 2003 16:32:50 -0500 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!headwall.stanford.edu!fu-berlin.de!uni-berlin.de!213-203-244-156.kunde.vdserver.DE!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 51 Original-NNTP-Posting-Host: 213-203-244-156.kunde.vdserver.de (213.203.244.156) Original-X-Trace: news.uni-berlin.de 1071692257 6680154 213.203.244.156 ([73968] 10430) User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.2 (gnu/linux) Cancel-Lock: sha1:2HdIIkoOnV+dFwbJ/RSMMkloRMI= Original-Xref: shelby.stanford.edu gnu.emacs.help:119448 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:15388 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:15388 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. 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'm wondering if there is a way to 'point' the emacs gdb process to > a shell that is currently running as a process 'inside'(?) emacs. > Then I could use eshell to connect to a remote machine, and then > issue either a gdb command in eshell and somehow have emacs-gdb take > control of the buffer, or issue a gdb command in emacs and have it > issue the command to the eshell (so the remote gdb will start). I think it should be possible to have GUD take control of an already existing buffer that's running GDB. But I don't know how to do that. Maybe GUD is not designed for this, so it could be difficult. But using eshell to "connect" to a remote machine seems a bit strange. Either you are using "cd /user@host:/path/to/dir" to do this connection. In that case, it's all fake -- no actual process is involved. Whenever you type something into eshell, then eshell will run that command as a shell command. And Tramp intercepts the shell-command action for its directories, so it kinda appears as if eshell was "connected" to the remote machine. But it isn't, really. The other possibility is that you are invoking ssh at the eshell prompt. That won't do much good, since eshell does not have good facilities for interacting with subprocesses. (The facilities aren't that bad, but eshell wasn't designed for it.) The third possibility is you're talking about M-x shell RET and not M-x eshell RET. In that case, everything is different ;-) But it remains difficult to use Tramp for compilation. Kai