Running pyflakes remotely with flymake and tramp in emacs?
Asked Answered
D

2

17

I'm trying to use flymake to run pyflakes, as suggested here

This works fine for local files, and almost works with remote files with a bit of tweaking, but I'm left with a problem where flymake/pyflakes 'modifies' the buffer when it runs (although nothing actually seems to change), which renders it a bit useless in practice (e.g. saving a file runs flymake which immediately modifies the buffer again).

Here's what I did to almost get it working:

  1. Installed pyflakes on the remote box.
  2. Customized my tramp-remote-process-environment variable so that pyflakes could be found in its PATH
  3. Used a variant of the code from the wiki link above. Obviously I excluded the check that disables it for remote buffers. Also, the (when (load "flymake" t) ...) construct didn't seem to work as I expected, but I'm not too worried about that.
  4. Re-defined (for test purposes -- advice should be fine if this can be made to work) the flymake-start-syntax-check-process function so that it uses start-file-process (which works with tramp) instead of start-process (which does not).

The change in #4 does not appear to cause any issues when processing a local file, but although this now enables flymake to run the remote pyflakes for the remote files (errors are highlighted as expected), in this instance the buffer is 'modified' whenever flymake runs.

I'm guessing that start-file-process, for remote processes, results in some additional return value/data that does not occur for local processes.

Does anyone have any insight/advice?

  • Emacs 23.1 and 23.2 on Ubuntu
  • Python 2.4.6
  • Pyflakes 0.4.0 (via easy_install)
Discontinuation answered 30/6, 2010 at 0:33 Comment(1)
Just a note: in 2014, the standard flymake you can install with elpa (i have version 0.4.16) include the flymake-run-in-place variable - simple customize this to nil and flymake will stores files in $TMPPinot
L
9

You need to tell flymake to create it's copy of the buffer somewhere locally, I prefer using the $TMP directory since this also allows me to use tramp on files in directories I don't have write permissions to.

You may want to checkout my fork of flymake-python since it does all this.

Luminiferous answered 27/8, 2011 at 22:10 Comment(2)
That sounds promising, but I'm no longer in a convenient position to test this. Kingpin, could you please let me know if there's a solution to be accepted?Discontinuation
hello there, @Ross Patterson. I'm using your modified version of flymake. It had a problem for files that haven't got .py extension, (but loads with python-mode) I have work around this by some help, and its pretty working on local python files. (with/without py.extension); (#14083475) However its not working with tramp over ssh. local buffers says flymake:0/2 on minibuffer whereas tramp buffer says only flymake. minor mode is opened but no highlighting happens. you got any idea? thanks.Bontebok
B
6

I have this fixed in my fork of Flymake (https://github.com/illusori/emacs-flymake).

It will either run the syntax check on the remote machine via Tramp, without the buffer-modification issue you're seeing; or you can set flymake-run-in-place to nil and it will run the syntax check on the local machine, just like flymake on a regular non-Tramp buffer.

Since it's fixed at the Flymake level, this fix works for all languages and syntax checks rather than just pyflakes.

If you're interested in details of why it's happening, basically when the Tramp handler for start-file-process kicks in, it dumps the login message for the connection onto the end of the current buffer before any output filter can be attached to the process.

Usually this manifests as people seeing the contents of /etc/issue appear at the end of their file along with "You have mail." and so on.

In your case it may be that the login message is empty or just a new-line, so you're not seeing any text being added, even though it's setting the buffer as being modified.

Brython answered 24/10, 2011 at 10:40 Comment(1)
Thank you for the info. That looks like an excellent collection of improvements you've made.Discontinuation

© 2022 - 2024 — McMap. All rights reserved.