Re: Setting gdb to use eshell buffer

[Kai Grossjohann]

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