[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: (font-lock-mode 1) does not always force font-lock

From: Alexander Pohoyda
Subject: Re: (font-lock-mode 1) does not always force font-lock
Date: 26 Oct 2003 12:32:51 +0100
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

Hrvoje Niksic <address@hidden> writes:

> > Hrvoje Niksic <address@hidden> writes:
> >
> >> > Yes, both cases work. If I comment out (font-lock-mode 1), things
> >> > still work.
> >> 
> >> Please repeat the tests with `emacs -q' then.
> >
> > OK. There is no difference whether the buffer is named "*foo*" or just
> > "foo". Both cases work.
> I'm afraid you tested the wrong thing.  You need to try "*foo*" and
> " *foo*", i.e. with and without the leading space in the buffer name.

Yes, indeed, I misread your original posting. Sorry for that.
Now I was able to reproduce the problem you described.

Please open the lisp/font-core.el file, function font-lock-mode, 
right at the beginning of the function, after very long comment, code
goes like this:

  ;; 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).
  (when (or noninteractive (eq (aref (buffer-name) 0) ?\ ))
    (setq font-lock-mode nil))
  (funcall font-lock-function font-lock-mode)

That's what happens: font-lock-default-function is called with nil
argument. So, the buffer is considered to be invisible.

I don't know whether this is a bug or not, but I'm wondering why
there's no such function:

(defun buffer-invisible-p (&optional buffer)
  "Return t if BUFFER is invisible.
No argument or nil as argument means use current buffer as BUFFER."
  (eq (aref (buffer-name buffer) 0) ?\ ))

do to the job.

Alexander Pohoyda <address@hidden>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44

reply via email to

[Prev in Thread] Current Thread [Next in Thread]