Re: compilation-mode, face, font-lock-face

[Anders Lindgren]

On Thu, Feb 2, 2017 at 8:31 PM, Davis Herring <address@hidden> wrote:

OK, I can understand that if there is no display then there
_cannot_ be any font-locking, so the `noninteractive' test
makes sense, I guess.

Even that is questionable -- there are many (unfortunate) situations in which font-lock is used to apply syntactically meaningful properties to the text that might then be used by Lisp programs.  It's fine if font-lock skips configuring the lack of display, of course, and it could be OK for it to skip setting the face property (since a program that depended on examining it could be said to be broken).  But even then, what if a non-interactive Emacs is supposed to be running tests of font-lock itself?

Fortunately, it's easy to bypass this test. `font-lock-fontify-region` can be called explicitly to add highlighting even in batch mode. Alternatively, `noninteractive` is a variable that can be bound to another value. For example, I do the following in one of my packages*:

            (let ((noninteractive nil))
              (font-lock-mode 1))

*) "e2ansi", a package that converts text with face information into ANSI sequences. You can configure "less" to run an emacs in batch mode to add syntax highlighting to anything viewed in the terminal. See the environment variable LESSOPEN and https://github.com/Lindydancer/e2ansi for more information.

But even then, what if a non-interactive Emacs is supposed to be running tests of font-lock itself?

Funny you should ask. I just published a collection of tests for font-lock the other day. It consists of real-world source files in various programming languages and font-lock reference files in "faceup" format. It run fine in batch mode as well as in the GUI. See https://github.com/Lindydancer/font-lock-regression-suite and https://github.com/Lindydancer/faceup for more information.

    -- Anders