On Mon, 05 Mar 2001, Tom Roche wrote:
>> However, although CPerl seems happy to edit remote files without
>> problem, I can't seem to compile them.

[EMAIL PROTECTED] 06 Mar 2001 13:19:19 +0100
> That's because the function compile-internal uses start-process to
> start the compilation, and start-process is restricted to the
> current host.
<snip>
> Alas, I haven't been able to make much progress, here. I know what
> to do, but I haven't done it.

A feeling with which I am _very_ familiar :-)

> (And finding all the places where start-process or call-process
> should be replaced with process-file is a big job.)

Well, perhaps a quick hack for the interim ?-) Seriously, I'd like to
propose two options, being fully aware that I lack the elisp chops to
implement them--I'm trusting the competencies of die Trampvolk will
rectify my deficiencies.

* Shelling out. If one is running in-band (as, conveniently, I am :-)
  one is already running a shell on the remote host. Could one then
  redefine (e.g.) 'tramp-compile-in-band' to run a
  remote-compile-command on the remote, redirect the (remote) output,
  copy the output back to the local host, and display it in a
  *compilation* buffer?

* Temp copying. Currently,

  tramp.info
  > In order to access remote files TRAMP needs to transfer their
  > content to the local machine temporarily.

  Since a file's content can be made local in the defined temp
  directory, why not just have a 'tramp-compile' that makes a local
  copy, and call 'compile' on that as normal? This would break
  external references, of course, but for preliminary hack that would
  suffice--it would be better than nothing. A more sophisticated hack
  could perhaps, on encountering an external reference, prompt the
  user to temp-copy the required file, or just go ahead and do it.

In comparison, shelling out would seem to be

+ cleaner

- requires an in-band method

+ would keep the file in its context (directory), which make
  resolution of references to other files easier

? tougher to implement 'next-error'?

while temp coping would seem to be

- messier (copying of files leads to greater possibility of divergent
  versioning)

+ easier to make work with the current 'compile'

? possibly harder to implement 'next-error'?

- harder to deal with external references

Am I missing anything?

Are either of these doable in reasonable time? 

Or must we await process-file?

FWIW, [EMAIL PROTECTED]

Reply via email to