On Thu, Feb 2, 2017 at 8:31 PM, Davis Herring <herring@lanl.gov> 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