emacs-flymake

This project is a fork of Pavel Kobyakov's excellent flymake.el to let me play around with some updates before contributing them upstream.

Features added so far:

• Support for queuing up syntax checks once a certain number are in-progress.
• Support for placing temporary files in the system temporary directory.
• Spawns only one buffer-modification timer check rather than one per buffer.
• Show multiple errors in tooltips.
• Improved support for remote files over Tramp.
• Improved error message classification. (err/warn/info, customizable regexp)
• Support for new languages: Javascript and CSS.
• Minor other bug fixes.

For a full list of changes, please refer to the Changes file.

Queued syntax checks

If you use desktop.el with hundreds of buffers open you've probably had problems when you restart emacs with flymake running: it'll try to run a syntax check on everything at once.

Now there's a limit of 4 syntax checks running at once, any more that are attempted go on a queue that will empty as one of the 4 slots frees up.

You can customize the number of parallel checks that run, or turn off the limit entirely with the 'flymake-max-parallel-syntax-checks' variable.

;; Let's run 8 checks at once instead.
(setq flymake-max-parallel-syntax-checks 8)

;; I don't want no steekin' limits.
(setq flymake-max-parallel-syntax-checks nil)

Use the system temporary directory for temp files

By default Flymake creates a temporary copy of the file being inspected in the same directory as the original file. This is helpful if you're using relative pathnames for includes, but not so helpful if you have something in your environment that's triggered by file changes in your project directory (continuous integration, webserver restarts, etc).

Now you can toggle between the two behaviours with the 'flymake-run-in-place' variable.

;; Yes, I want my copies in the same dir as the original.
(setq flymake-run-in-place t)

;; Nope, I want my copies in the system temp dir.
(setq flymake-run-in-place nil)
;; This lets me say where my temp dir is.
(setq temporary-file-directory "~/.emacs.d/tmp/")

One buffer modification timer check

Again, if you have multiple hundreds of buffers open, original Flymake would start thrashing your CPU trying to keep up with 1-second timer looking for modifications for every buffer, my laptop would have emacs sat at 60-90% CPU doing nothing but try to check for whether buffers had been modified.

Now only a single timer is spawned, it still runs once per second but only looks for changes in the current buffer.

This is much more CPU-friendly but also means that if you quickly switch away from a buffer after making changes, the syntax check may not be run until you return to the buffer. (The last-modified value is still retained per-buffer so the changes will still be detected once you return for long enough for the 1-second timer to happen.)

Show multiple errors in tooltips

The tooltips containing errors can now also be configured to include more than one error with the 'flymake-number-of-errors-to-display' variable:

;; I want to see at most the first 4 errors for a line.
(setq flymake-number-of-errors-to-display 4)

;; I want to see all errors for the line.
(setq flymake-number-of-errors-to-display nil)

Improved support for remote files over Tramp

Flymake has a few odd errors when operating on Tramp files, this version fixes bypasses most of the errors if you're running with flymake-run-in-place set to nil. This ensures that the syntax check is run in temporary-file-directory, which is probably the local machine rather than the remote.

If flymake-run-in-place is set to t things are a little more complicated: the syntax check will be run in the same directory as the original file, this (usually) means that it will run in a shell on the remote machine.

Flymake attempts to cope with this gracefully, but there's a couple of odd behaviours in Tramp which make this difficult:

• Tramp places the contents of the remote shell login message at the end of the buffer being syntax-checked. This version of Flymake takes steps to prevent this from modifying the buffer in any way.
• If the syntax-check command to run is not found on the remote machine, the command process just hangs and never completes. At the moment Flymake has no special handling of this situation and it will mean that the syntax check never appears to finish.

Improved error message classification

Error messages from the syntax checker can now be classed as info messages in addition or error and warning, and there's a new face to highlight info messages in: flymake-infoline.

In addition, the separation of errors into err/warn/info is now handled by the customizable regexps: flymake-warn-line-regexp and flymake-info-line-regexp. The default fall-through if neither regexp matches is still to classify the message as an error.

Support for new languages

• Javascript support has been added by running JSHint if it's available.

  There's a number of other good ways of hooking up Javascript support out there, this is by no means the most complete and awesome implementation, but it's pretty simple to get running if you have node.js and npm installed:

  npm -g install jshint
  

• CSS support has been added by running CSSLint if it's available:

  npm -g install csslint
  

• RPM Specfile support has been added by running rpmlint if it's available.

• gettext() .po file support has been provided by msgfmt if it's available.

Other bug fixes

• Logging no longer errors.
• Log files are now proper logs rather than last-message-only.
• Log files now have timestamps to help debugging where time is going.
• You can customize where the log is created with flymake-log-file-name.
• Provides hooks so that flymake-cursor doesn't need to wrap our functions.
• Compile is now clean without warnings.
• Support for invoking correct perl under perlbrew multiple-installs.
• No longer prompt about running flymake processes when killing buffers.

Known Issues

• Perl syntax checking uses "perl -c", which executes BEGIN blocks, this can be considered a security vulnerability when opening untrusted files. For more information: http://stackoverflow.com/a/12908487/870000