compilation-mode, face, font-lock-face

compilation-mode, face, font-lock-face

[Stephen Leake]

I have an external program that produces messages similar to compilation
errors; they have file name and line numbers.

However, the program is designed to start once, then accept commands on
stdin.

So I can't use 'compilation-start' to send a new command to the program,
but I'd like to use the compilation machinery to highlight the file/line
and navigate to them.

So I start the process, and in the associated buffer I call
compilation-mode, and set compilation-error-regexp-alist.

The file/line locations are recognized, and next-error jumps to them.

However, the buffer is not highlighted.

describe-text-properties shows that there is a font-lock-face property
set appropriately, but the text shows as plain black.

Comparing to a compilation buffer created via M-x compile, I can't
figure out what is different.

As I understand it, 'font-lock-face' is supposed to be set only by
font-lock; 'face' should be set by any other mechanism. So I don't
understand why compile.el is setting 'font-lock-face' instead of 'face'.

Apparently M-x compile does something to font-lock that I'm not doing.

Can anyone explain what's going on?

-- 
-- Stephe

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

[Michael Heerdegen]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> As I understand it, 'font-lock-face' is supposed to be set only by
> font-lock; 'face' should be set by any other mechanism.

AFAIK, no - rather the opposite.

'face' is dynamically updated by font-lock, so if you modify this text
property directly in a buffer that has font-lock turned on, you get no
visible effect most of the time.  You have to use font-lock-face in this
case, as an instruction to font-lock to use the respective face when
fontifying the buffer.  See (info "(elisp) Special Properties").


Michael.

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

[Stephen Leake]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Stephen Leake <stephen_leake@stephe-leake.org> writes:
>
>> As I understand it, 'font-lock-face' is supposed to be set only by
>> font-lock; 'face' should be set by any other mechanism.
>
> AFAIK, no - rather the opposite.
>
> 'face' is dynamically updated by font-lock, so if you modify this text
> property directly in a buffer that has font-lock turned on, you get no
> visible effect most of the time.  You have to use font-lock-face in this
> case, as an instruction to font-lock to use the respective face when
> fontifying the buffer.  See (info "(elisp) Special Properties").

Ok, that at least defines what the 'face' and 'font-lock-face'
properties are supposed to do.

But it's still not working; 'font-lock-face' text properties are
present, but do not affect the display.

Hmm; the info says this can happen if font-lock-mode is disabled. I have
it turned on globally, and did nothing to turn it off. However, M-:
font-lock-mode returns nil, so somehow it is being disabled.

Ah; font-lock-mode contains this:

  (when (or noninteractive (eq (aref (buffer-name) 0) ?\s))
    (setq font-lock-mode nil))

my buffer name begins with a space; it is supposed to be normally
invisible to users, only exposed when it has interesting stuff. Removing
that space enables font-lock.

-- 
-- Stephe

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

[Drew Adams]

> font-lock-mode returns nil, so somehow it is being disabled.
> Ah; font-lock-mode contains this:
> 
>   (when (or noninteractive (eq (aref (buffer-name) 0) ?\s))
>     (setq font-lock-mode nil))
> 
> my buffer name begins with a space; it is supposed to be normally
> invisible to users, only exposed when it has interesting stuff. Removing
> that space enables font-lock.

That part of the `font-lock-mode' definition seems misguided, to me.

In general, a mode should not, itself, decide when it is to be
turned on or off.  (Yes, there can be exceptions, but they should
apply only when it is impossible or it never makes sense for the
mode to be enabled.)

This is the comment before that code:

 ;; Don't turn on Font Lock mode if we don't have a display (we're
 ;; running a batch job) or if the buffer is invisible (the name
 ;; starts with a space).

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.

But the part about the buffer name seems very wrong.  Not to
mention that the comment does not speak the truth: a buffer is _not_
necessarily invisible just because its name starts with a space.

Users are perfectly capable of displaying a buffer whose name begins
with a space.  And there is no hard reason why such a buffer should
not be entitled to font-locking, if that's what someone wants.

To me, this seems like a gratuitous bug.

A guess is that this was added as a "convenience", so code that uses
font-lock-mode need not, itself, turn the mode off for a buffer with
a space-prefixed name.  That's a reasonable use case, but hard-coding
that behavior in the mode itself is not the right approach, I think.

You should be able to turn `font-lock-mode' on for a buffer without
regard to its name.  If we feel the need for a mode that reflects
the common use case of, by default, inhibiting `font-lock-mode'
based on buffer name, then I suggest we add a variable,
`font-lock-inhibiting-buffer-name-regexp', or
`font-lock-ignore-buffer-regexp', or some such, whose value
is a regexp which, if matched by a buffer name, inhibits the mode.
(It could also be a list of such regexps.)

The code could then be something like this:

(defvar font-lock-ignore-buffer-regexp "\\` "
  "Regexp match of this against buffer name turns off `font-lock-mode'.")

;; Turn off the mode if we don't have a display (we're running a
;; batch job) or if the buffer name requires it.
(when (or noninteractive
          (string-match font-lock-ignore-buffer-regexp (buffer-name)))
  (setq font-lock-mode  nil))

(The variable could also be a defcustom.)

Exactly that regexp is used for `desktop-buffers-not-to-save', BTW:

(defcustom desktop-buffers-not-to-save "\\` "
  "Regexp identifying buffers that are to be excluded from saving."
  :type '(choice (const :tag "None" nil)
		 regexp)
  :version "24.4" ; skip invisible temporary buffers
  :group 'desktop)

(Unfortunately, the doc string here is wrong/incomplete: the value
is not necessarily a regexp.)

Similarly, option `ido-ignore-buffers':

(defcustom ido-ignore-buffers '("\\` ")
  "List of regexps or functions matching buffer names to ignore...

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

[Davis Herring]

> 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?

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or 
too sparse, it is because mass-energy conversion has occurred during 
shipping.

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

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 1912 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2969 bytes --]