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

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

[Hrvoje Niksic]

I have code that needs to force fontification of a file loaded from
disk without affecting buffers visiting the file.  What I tried was:

(with-temp-buffer
  (insert-file-contents FILE)
  (let ((buffer-file-name FILE))  ; for normal-mode
    (normal-mode)
    (font-lock-mode 1)
    ;; Here the buffer should be fontified and font-lock-mode turned
    ;; on.
    font-lock-mode))

This returns nil because `(font-lock-mode 1)' does not force
font-lock, contrary to the docstring which, in GNU Emacs 21.2.1,
states:

    With arg, turn Font Lock mode off if and only if arg is a
    non-positive number; if arg is nil, toggle Font Lock mode;
    anything else turns Font Lock on.

I assume the problem is that the buffer is that the buffer in question
is temporary.  But `(font-lock-mode 1)' should IMHO still force
font-lock.  And if not, there should be a way to say, "yes, I know
what I'm doing and I really want to fontify this temporary buffer."

A workaround that works for me is to add:

  (unless font-lock-mode
    (font-lock-fontify-buffer))

but that kind of solution might not work elsewhere.

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

[Richard Stallman]

    This returns nil because `(font-lock-mode 1)' does not force
    font-lock, contrary to the docstring which, in GNU Emacs 21.2.1,
    states:

	With arg, turn Font Lock mode off if and only if arg is a
	non-positive number; if arg is nil, toggle Font Lock mode;
	anything else turns Font Lock on.

    I assume the problem is that the buffer is that the buffer in question
    is temporary.

that seems like a bug to me.  perhaps it is a consequence of a feature
meant for some other case.  what code tests this?

can u suggest a patch?

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

[Hrvoje Niksic]

Richard Stallman <rms@gnu.org> writes:

>     This returns nil because `(font-lock-mode 1)' does not force
>     font-lock, contrary to the docstring which, in GNU Emacs 21.2.1,
>     states:
>
> 	With arg, turn Font Lock mode off if and only if arg is a
> 	non-positive number; if arg is nil, toggle Font Lock mode;
> 	anything else turns Font Lock on.
>
>     I assume the problem is that the buffer is that the buffer in
>     question is temporary.
>
> that seems like a bug to me.  perhaps it is a consequence of a
> feature meant for some other case.

It was probably meant to prevent unwanted fontification of temporary
buffers for users who turn on font-lock from a global hook or who use
global-font-lock-mode.

The idea is correct, but the place is wrong.  The code that excludes
temporary buffers from font-lock should be in global-font-lock-mode or
perhaps in turn-on-font-lock, but not in font-lock-mode proper.

> what code tests this?

I don't have the sources handy.  It seems that the code recognizes the
buffer as temporary by checking for names that begins with space.  For
instance, this works (returns t):

(let ((newbuf (generate-new-buffer "*foo*")))
  (with-current-buffer newbuf
    (c-mode)
    (font-lock-mode 1)
    (prog1 font-lock-mode
      (kill-buffer (current-buffer)))))

Change "*foo*" to " *foo*", and it no longer works, i.e. it returns
nil.

> can u suggest a patch?

I don't have a patch, sorry.

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

[Alexander Pohoyda]

Hrvoje Niksic <hniksic@xemacs.org> writes:

> > what code tests this?
> 
> I don't have the sources handy.  It seems that the code recognizes
> the buffer as temporary by checking for names that begins with
> space.  For instance, this works (returns t):
> 
> (let ((newbuf (generate-new-buffer "*foo*")))
>   (with-current-buffer newbuf
>     (c-mode)
>     (font-lock-mode 1)
>     (prog1 font-lock-mode
>       (kill-buffer (current-buffer)))))
> 
> Change "*foo*" to " *foo*", and it no longer works, i.e. it returns
> nil.

I have just tested it on recent Emacs and this code always works
(returns t). 


-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44

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

[Hrvoje Niksic]

Alexander Pohoyda <alexander.pohoyda@gmx.net> writes:

> Hrvoje Niksic <hniksic@xemacs.org> writes:
>
>> > what code tests this?
>> 
>> I don't have the sources handy.  It seems that the code recognizes
>> the buffer as temporary by checking for names that begins with
>> space.  For instance, this works (returns t):
>> 
>> (let ((newbuf (generate-new-buffer "*foo*")))
>>   (with-current-buffer newbuf
>>     (c-mode)
>>     (font-lock-mode 1)
>>     (prog1 font-lock-mode
>>       (kill-buffer (current-buffer)))))
>> 
>> Change "*foo*" to " *foo*", and it no longer works, i.e. it returns
>> nil.
>
> I have just tested it on recent Emacs and this code always works
> (returns t).

Then the bug may have been fixed already.  Could you please also check
whether the buffer is actually fontified?  For example:

(let ((newbuf (generate-new-buffer "*foo*")))
  (with-current-buffer newbuf
    (c-mode)
    (insert "\"a string\"")
    (font-lock-mode 1))
  (switch-to-buffer newbuf))

If things work, using both "*foo*" and with " *foo" should result in a
buffer with fontified "a string".

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

[Alexander Pohoyda]

Hrvoje Niksic <hniksic@xemacs.org> writes:

> >> > what code tests this?
> >> 
> >> I don't have the sources handy.  It seems that the code recognizes
> >> the buffer as temporary by checking for names that begins with
> >> space.  For instance, this works (returns t):
> >> 
> >> (let ((newbuf (generate-new-buffer "*foo*")))
> >>   (with-current-buffer newbuf
> >>     (c-mode)
> >>     (font-lock-mode 1)
> >>     (prog1 font-lock-mode
> >>       (kill-buffer (current-buffer)))))
> >> 
> >> Change "*foo*" to " *foo*", and it no longer works, i.e. it
> >> returns nil. 
> >
> > I have just tested it on recent Emacs and this code always works
> > (returns t).
> 
> Then the bug may have been fixed already.  Could you please also
> check whether the buffer is actually fontified?  For example:
> 
> (let ((newbuf (generate-new-buffer "*foo*")))
>   (with-current-buffer newbuf
>     (c-mode)
>     (insert "\"a string\"")
>     (font-lock-mode 1))
>   (switch-to-buffer newbuf))
> 
> If things work, using both "*foo*" and with " *foo" should result in
> a buffer with fontified "a string".

Yes, both cases work. If I comment out (font-lock-mode 1), things
still work.


-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44

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

[Hrvoje Niksic]

Alexander Pohoyda <alexander.pohoyda@gmx.net> writes:

> Yes, both cases work. If I comment out (font-lock-mode 1), things
> still work.

Please repeat the tests with `emacs -q' then.

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

[Alexander Pohoyda]

Hrvoje Niksic <hniksic@xemacs.org> 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.
If I comment out (font-lock-mode 1), both cases does not work: a
string is not fontified.


-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44

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

[Hrvoje Niksic]

Alexander Pohoyda <alexander.pohoyda@gmx.net> writes:

> Hrvoje Niksic <hniksic@xemacs.org> 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.
Whether the buffer name contains asterisks or not is, as you
discovered, irrelevant.

> If I comment out (font-lock-mode 1), both cases does not work: a
> string is not fontified.

There is no use in testing that.  The code is not expected to fontify
anything when you remove `(font-lock-mode 1)'.

If you're not sure what to test, you should contact me privately with
your findings, to prevent needless traffic on the development list.

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

[Alexander Pohoyda]

Hrvoje Niksic <hniksic@xemacs.org> writes:

> > Hrvoje Niksic <hniksic@xemacs.org> 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 <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44

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

[Hrvoje Niksic]

Alexander Pohoyda <alexander.pohoyda@gmx.net> writes:

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

I propose removing the buffer-name check, at least when the argument
to font-lock-mode is positive.

The code that prevents fontification of temporary buffers would be
better placed in the hook function installed by
`global-font-lock-mode'.

> I'm wondering why there's no such function:
>
> (defun buffer-invisible-p (&optional buffer)
[...]

I don't see a good use for this function.  Very little code should
care whether the buffer they're working on is temporary or not --
font-lock is the exception here, and even font-lock got it wrong
(IMHO).  Lisp code should preferrably check for specific features,
such as buffer-local variables, to modify its behavior.  Also, buffers
can be renamed, which would change their "invisibility" status.

(Note that the manual doesn't even use the term "invisible" for such
buffers.  It calls them "ephemeral" in one place.)

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

[Stefan Monnier]

>> ;; 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))

> I propose removing the buffer-name check, at least when the argument
> to font-lock-mode is positive.

I always thought that the whole thing should be removed (i.e. including the
noninteractive check: after all, you might want to use it in batch with
ps-print or htmlize), but I never cared enough to try and convince the
rest of the developers.
So for what it's worth, I completely agree,


        Stefan

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

[Richard Stallman]

i think that explicit call to font-lock-mode shd apply to all
buffers.  instead global-font-lock-mode should check to avoid temp bufs.
someone want to do it? 

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

[Alexander Pohoyda]

> i think that explicit call to font-lock-mode shd apply to all
> buffers.

Index: font-core.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/font-core.el,v
retrieving revision 1.23
diff -u -r1.23 font-core.el
--- font-core.el        1 Sep 2003 15:45:12 -0000       1.23
+++ font-core.el        28 Oct 2003 22:04:47 -0000
@@ -149,10 +149,6 @@
 your own function which is called when `font-lock-mode' is toggled via
 `font-lock-function'. "
   nil nil nil
-  ;; 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)
   ;; Arrange to unfontify this buffer if we change major mode later.
   (if font-lock-mode

That's what Stefan agreed with, if I got him right.


>          instead global-font-lock-mode should check to avoid temp bufs.
> someone want to do it? 

I don't know how to do that because global-font-lock-mode is not a
function itself, look here:

(easy-mmode-define-global-mode
 global-font-lock-mode font-lock-mode turn-on-font-lock-if-enabled
 :extra-args (dummy))

An advice is very welcome.


-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44

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

[Alexander Pohoyda]

Richard Stallman <rms@gnu.org> writes:

> i think that explicit call to font-lock-mode shd apply to all
> buffers.  instead global-font-lock-mode should check to avoid temp bufs.
> someone want to do it? 

Please excuse me that it took so long.

Here's the patch. Note that it avoids invisible, not temp buffers.


Index: font-core.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/font-core.el,v
retrieving revision 1.23
diff -u -r1.23 font-core.el
--- font-core.el	1 Sep 2003 15:45:12 -0000	1.23
+++ font-core.el	18 Nov 2003 21:02:45 -0000
@@ -149,10 +149,6 @@
 your own function which is called when `font-lock-mode' is toggled via
 `font-lock-function'. "
   nil nil nil
-  ;; 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)
   ;; Arrange to unfontify this buffer if we change major mode later.
   (if font-lock-mode
@@ -282,8 +278,14 @@
   :group 'font-lock)
 
 (defun turn-on-font-lock-if-enabled ()
-  (unless (and (eq (car-safe font-lock-global-modes) 'not)
-	       (memq major-mode (cdr font-lock-global-modes)))
+  (unless (or
+	   ;; we don't have a display (we're running a batch job)
+	   noninteractive
+	   ;; the buffer is invisible (the name starts with a space)
+	   (eq (aref (buffer-name) 0) ?\ )
+	   ;; this mode is in the list which is negative
+	   (and (eq (car-safe font-lock-global-modes) 'not)
+		(memq major-mode (cdr font-lock-global-modes))))
     (let (inhibit-quit)
       (turn-on-font-lock))))
 


-- 
Alexander Pohoyda <alexander.pohoyda@gmx.net>
PGP Key fingerprint: 7F C9 CC 5A 75 CD 89 72  15 54 5F 62 20 23 C6 44