Re: compiling remote rst files

[Hans Halvorson]

Michael,

I have pasted in below the definition of the "rst-compile" in rst.el.
The problem is with the call to "rst-compile-find-conf" in the first
let clause.  This function tries to search for a file called
"docutils.conf" in all directories above the directory of the current
buffer.  I do not know if that function is strictly incompatible with
Tramp, or whether it just takes a very long time to search on some
remote hosts.  But I have waited for up to two minutes after calling
rst-compile before pressing C-g to cancel.

It is my opinion that the writers of rst.el should remove that call to
rst-compile-find-conf; it is far too expensive an operation in any
case.  But until they do that, should Tramp try to disable the search?
For now, I just use "compile" directly with Tramp.  Remote compilation
is not quite working: it does not terminate properly -- Emacs is not
receiving the signal that the compilation is finished.  For example,
if I do "Compile command: ls | grep hans", then the *compilation*
buffer is:


>    -*- mode: compilation; default-directory: 
> "/ssh:hats.princeton.edu:/u/anonymous/public_html/" -*-
>    Compilation started at Wed Jan 10 05:30:20

>    ls | grep hans
>    hans.jpg
>    exit
>    Connection to hats.princeton.edu closed.
>    $ 


At this point, the modeline still reads "(Compilation:run Compiling)",
and if I call "compile" again, it says "A compilation process is
running; kill it?".

Best wishes,
Hans


(defun rst-compile (&optional pfxarg)
  "Compile command to convert reST document into some output file.
Attempts to find configuration file, if it can, overrides the
options."
  (interactive "P")
  ;; Note: maybe we want to check if there is a Makefile too and not do anything
  ;; if that is the case.  I dunno.
  (let* ((toolset (cdr (assq (if pfxarg
                                 rst-compile-secondary-toolset
                               rst-compile-primary-toolset)
                        rst-compile-toolsets)))
         (command (car toolset))
         (extension (cadr toolset))
         (options (caddr toolset))
         (conffile (rst-compile-find-conf))
         (bufname (file-name-nondirectory buffer-file-name))
         (outname (file-name-sans-extension bufname)))

    ;; Set compile-command before invocation of compile.
    (set (make-local-variable 'compile-command)
         (mapconcat 'identity
                    (list command
                          (or options "")
                          (if conffile
                              (concat "--config=\"" conffile "\"")
                            "")
                          bufname
                          (concat outname extension))
                    " "))

    ;; Invoke the compile command.
    (if (or compilation-read-command current-prefix-arg)
        (call-interactively 'compile)
      (compile compile-command))
    ))

(defun rst-compile-find-conf ()
  "Look for the configuration file in the parents of the current path."
  (interactive)
  (let ((file-name "docutils.conf")
        (buffer-file (buffer-file-name)))
    ;; Move up in the dir hierarchy till we find a change log file.
    (let ((dir (file-name-directory buffer-file)))
      (while (and (or (not (string= "/" dir)) (setq dir nil) nil)
                  (not (file-exists-p (concat dir file-name))))
        ;; Move up to the parent dir and try again.
        (setq dir (expand-file-name (file-name-directory
                                     (directory-file-name
                                     (file-name-directory dir))))) )
      (or (and dir (concat dir file-name)) nil)
    )))

At Tue, 09 Jan 2007 16:48:41 +0100,
Michael Albinus wrote:
> 
> Hans Halvorson <address@hidden> writes:
> 
> Hi Hans,
> 
> > Tramp 2.1.8_pre (CVS, January 9, 2007) does not yet play nicely with
> > remote compilation of RestructedText files (rst.el), which uses
> > compile.el.  I will take a closer look at this issue hopefully soon,
> > so that I can give a more helpful description of the problem.
> 
> Please do. Execution of commands on the remote side is not widely used
> until now, so I'm glad with every feedback I receive.
> 
> On the other hand I plan the release of 2.1.8 for next weekend, so if
> you want get something to fix for _this_ release I would need your
> report soon.
> 
> > Best wishes,
> > Hans
> 
> Best regards, Michael.
>