all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Stephen Leake <stephen_leake@stephe-leake.org>,
	emacs-devel <emacs-devel@gnu.org>
Subject: RE: compilation-mode, face, font-lock-face
Date: Thu, 2 Feb 2017 09:33:20 -0800 (PST)	[thread overview]
Message-ID: <9900a3e7-0c34-47ed-92df-e822e7089859@default> (raw)
In-Reply-To: <867f581qwq.fsf@stephe-leake.org>

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



  reply	other threads:[~2017-02-02 17:33 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-02 10:52 compilation-mode, face, font-lock-face Stephen Leake
2017-02-02 11:52 ` Michael Heerdegen
2017-02-02 16:47   ` Stephen Leake
2017-02-02 17:33     ` Drew Adams [this message]
2017-02-02 19:31       ` Davis Herring
2017-02-02 20:43         ` Anders Lindgren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9900a3e7-0c34-47ed-92df-e822e7089859@default \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=stephen_leake@stephe-leake.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.