[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Setting gdb to use eshell buffer
From: |
Kai Grossjohann |
Subject: |
Re: Setting gdb to use eshell buffer |
Date: |
Sat, 31 Jan 2004 21:14:31 +0100 |
User-agent: |
Gnus/5.110002 (No Gnus v0.2) Emacs/21.2 (gnu/linux) |
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