Re: Setting gdb to use eshell buffer

[Kai Grossjohann <kai@emptydomain.de>]

Kevin Rodgers <ihs_4664@yahoo.com> 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