unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Re: (font-lock-mode 1) does not always force font-lock
       [not found] <m3smlkygno.fsf@hniksic.iskon.hr>
@ 2003-10-23 18:38 ` Richard Stallman
  2003-10-23 22:30   ` Hrvoje Niksic
  0 siblings, 1 reply; 14+ messages in thread
From: Richard Stallman @ 2003-10-23 18:38 UTC (permalink / raw)
  Cc: emacs-devel

    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?

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: (font-lock-mode 1) does not always force font-lock
  2003-10-23 18:38 ` (font-lock-mode 1) does not always force font-lock Richard Stallman
@ 2003-10-23 22:30   ` Hrvoje Niksic
  2003-10-24  5:22     ` Alexander Pohoyda
  0 siblings, 1 reply; 14+ messages in thread
From: Hrvoje Niksic @ 2003-10-23 22:30 UTC (permalink / raw)
  Cc: emacs-devel

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.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: (font-lock-mode 1) does not always force font-lock
  2003-10-23 22:30   ` Hrvoje Niksic
@ 2003-10-24  5:22     ` Alexander Pohoyda
  2003-10-24  9:49       ` Hrvoje Niksic
  0 siblings, 1 reply; 14+ messages in thread
From: Alexander Pohoyda @ 2003-10-24  5:22 UTC (permalink / raw)
  Cc: rms, emacs-devel

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: (font-lock-mode 1) does not always force font-lock
  2003-10-24  5:22     ` Alexander Pohoyda
@ 2003-10-24  9:49       ` Hrvoje Niksic
  2003-10-24 19:12         ` Alexander Pohoyda
  0 siblings, 1 reply; 14+ messages in thread
From: Hrvoje Niksic @ 2003-10-24  9:49 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: (font-lock-mode 1) does not always force font-lock
  2003-10-24  9:49       ` Hrvoje Niksic
@ 2003-10-24 19:12         ` Alexander Pohoyda
  2003-10-24 20:15           ` Hrvoje Niksic
  0 siblings, 1 reply; 14+ messages in thread
From: Alexander Pohoyda @ 2003-10-24 19:12 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: (font-lock-mode 1) does not always force font-lock
  2003-10-24 19:12         ` Alexander Pohoyda
@ 2003-10-24 20:15           ` Hrvoje Niksic
  2003-10-25  7:35             ` Alexander Pohoyda
  0 siblings, 1 reply; 14+ messages in thread
From: Hrvoje Niksic @ 2003-10-24 20:15 UTC (permalink / raw)
  Cc: emacs-devel

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.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: (font-lock-mode 1) does not always force font-lock
  2003-10-24 20:15           ` Hrvoje Niksic
@ 2003-10-25  7:35             ` Alexander Pohoyda
  2003-10-25  9:52               ` Hrvoje Niksic
  0 siblings, 1 reply; 14+ messages in thread
From: Alexander Pohoyda @ 2003-10-25  7:35 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: (font-lock-mode 1) does not always force font-lock
  2003-10-25  7:35             ` Alexander Pohoyda
@ 2003-10-25  9:52               ` Hrvoje Niksic
  2003-10-26 11:32                 ` Alexander Pohoyda
  0 siblings, 1 reply; 14+ messages in thread
From: Hrvoje Niksic @ 2003-10-25  9:52 UTC (permalink / raw)
  Cc: emacs-devel

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.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: (font-lock-mode 1) does not always force font-lock
  2003-10-25  9:52               ` Hrvoje Niksic
@ 2003-10-26 11:32                 ` Alexander Pohoyda
  2003-10-26 16:56                   ` Hrvoje Niksic
  0 siblings, 1 reply; 14+ messages in thread
From: Alexander Pohoyda @ 2003-10-26 11:32 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: (font-lock-mode 1) does not always force font-lock
  2003-10-26 11:32                 ` Alexander Pohoyda
@ 2003-10-26 16:56                   ` Hrvoje Niksic
  2003-10-26 19:07                     ` Stefan Monnier
  0 siblings, 1 reply; 14+ messages in thread
From: Hrvoje Niksic @ 2003-10-26 16:56 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: (font-lock-mode 1) does not always force font-lock
  2003-10-26 16:56                   ` Hrvoje Niksic
@ 2003-10-26 19:07                     ` Stefan Monnier
  2003-10-27 23:44                       ` Richard Stallman
  0 siblings, 1 reply; 14+ messages in thread
From: Stefan Monnier @ 2003-10-26 19:07 UTC (permalink / raw)
  Cc: Alexander Pohoyda, emacs-devel

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: (font-lock-mode 1) does not always force font-lock
  2003-10-26 19:07                     ` Stefan Monnier
@ 2003-10-27 23:44                       ` Richard Stallman
  2003-10-28 22:09                         ` Alexander Pohoyda
  2003-11-18 21:13                         ` Alexander Pohoyda
  0 siblings, 2 replies; 14+ messages in thread
From: Richard Stallman @ 2003-10-27 23:44 UTC (permalink / raw)
  Cc: hniksic, alexander.pohoyda, emacs-devel

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? 

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: (font-lock-mode 1) does not always force font-lock
  2003-10-27 23:44                       ` Richard Stallman
@ 2003-10-28 22:09                         ` Alexander Pohoyda
  2003-11-18 21:13                         ` Alexander Pohoyda
  1 sibling, 0 replies; 14+ messages in thread
From: Alexander Pohoyda @ 2003-10-28 22:09 UTC (permalink / raw)
  Cc: hniksic, Stefan Monnier, emacs-devel

> 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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: (font-lock-mode 1) does not always force font-lock
  2003-10-27 23:44                       ` Richard Stallman
  2003-10-28 22:09                         ` Alexander Pohoyda
@ 2003-11-18 21:13                         ` Alexander Pohoyda
  1 sibling, 0 replies; 14+ messages in thread
From: Alexander Pohoyda @ 2003-11-18 21:13 UTC (permalink / raw)
  Cc: alex, hniksic, monnier, rms

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2003-11-18 21:13 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <m3smlkygno.fsf@hniksic.iskon.hr>
2003-10-23 18:38 ` (font-lock-mode 1) does not always force font-lock Richard Stallman
2003-10-23 22:30   ` Hrvoje Niksic
2003-10-24  5:22     ` Alexander Pohoyda
2003-10-24  9:49       ` Hrvoje Niksic
2003-10-24 19:12         ` Alexander Pohoyda
2003-10-24 20:15           ` Hrvoje Niksic
2003-10-25  7:35             ` Alexander Pohoyda
2003-10-25  9:52               ` Hrvoje Niksic
2003-10-26 11:32                 ` Alexander Pohoyda
2003-10-26 16:56                   ` Hrvoje Niksic
2003-10-26 19:07                     ` Stefan Monnier
2003-10-27 23:44                       ` Richard Stallman
2003-10-28 22:09                         ` Alexander Pohoyda
2003-11-18 21:13                         ` Alexander Pohoyda

Code repositories for project(s) associated with this public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).