Global Font Lock by default

Global Font Lock by default

[Richard M. Stallman]

The main obstacle to enabling Global Font Lock by default
was that it uses more memory and cause an Emacs session to
die sooner.

I've fixed some bugs in the way memory full is handled.  !MEM FULL!
should appear in the mode line once Emacs can't get more Lisp memory.
If you kill things and that results in making space available, !MEM
FULL! should disappear.

However, this does not work.  The reason is that the value
of BYTES_USED, which I believe is obtained from mallinfo,
does not seem to decrease even when a large buffer is killed.

I don't have any documentation for mallinfo.
Can someone send it to me?

Re: Global Font Lock by default

[Kim F. Storm]

"Richard M. Stallman" <rms@gnu.org> writes:

> The main obstacle to enabling Global Font Lock by default
> was that it uses more memory and cause an Emacs session to
> die sooner.

Die?  Sooner?  Buy more RAM then!

>
> I've fixed some bugs in the way memory full is handled.  !MEM FULL!
> should appear in the mode line once Emacs can't get more Lisp memory.
> If you kill things and that results in making space available, !MEM
> FULL! should disappear.

I don't recall ever to have  experienced a memory full in emacs,
so I'm puzzled about the amount of changes related to that specific
problem in emacs 22 (when memory is more plenty than ever?)


>
> However, this does not work.  The reason is that the value
> of BYTES_USED, which I believe is obtained from mallinfo,
> does not seem to decrease even when a large buffer is killed.

This approach is probably not very protable.

Can't you just try to malloc (and free) 10000 bytes, and report
MEM FULL if it fails?

Maybe you could add a "memory-full-hook" which could contain functions
to be run when memory runs full -- this could involve turning off
font-lock, kill some buffers (which?), and other things that may free
up memory.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Global Font Lock by default

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> "Richard M. Stallman" <rms@gnu.org> writes:
>
>> The main obstacle to enabling Global Font Lock by default
>> was that it uses more memory and cause an Emacs session to
>> die sooner.
>
> Die?  Sooner?  Buy more RAM then!

I come to praise Emacs, not buy more RAM.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Global Font Lock by default

[Stuart D. Herring]

> storm@cua.dk (Kim F. Storm) writes:
>
>> "Richard M. Stallman" <rms@gnu.org> writes:
>>
>>> The main obstacle to enabling Global Font Lock by default
>>> was that it uses more memory and cause an Emacs session to
>>> die sooner.
>>
>> Die?  Sooner?  Buy more RAM then!
>
> I come to praise Emacs, not buy more RAM.
>
> --
> David Kastrup, Kriemhildstr. 15, 44793 Bochum

More for DEVEL.HUMOR (this from before it was created).

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: Global Font Lock by default

[Richard M. Stallman]

    > However, this does not work.  The reason is that the value
    > of BYTES_USED, which I believe is obtained from mallinfo,
    > does not seem to decrease even when a large buffer is killed.

    This approach is probably not very protable.

It is only used with DOUG_LEA_MALLOC, but that case is very
important, since it is used on GNU/Linux.

    Can't you just try to malloc (and free) 10000 bytes, and report
    MEM FULL if it fails?

It already does that; the issue here is what to do afterward.
The idea is that when more memory is available Emacs should
refill its memory reserve.  The question is how to tell
when more memory is available.

    Maybe you could add a "memory-full-hook" which could contain functions
    to be run when memory runs full -- this could involve turning off
    font-lock, kill some buffers (which?), and other things that may free
    up memory.

That part is done--I made these things test `memory-full'.


I found the mallinfo information and fixed the problem.
I think this works now.

So now I think we are ready to enable font-lock by default.
Would someone like to do that?

Re: Global Font Lock by default

[Dan Nicolaescu]

"Richard M. Stallman" <rms@gnu.org> writes:

  > So now I think we are ready to enable font-lock by default.
  > Would someone like to do that?

I've done the first part of this: add to loadup.el the needed files
and increazed the puresize so that it does not overflow. 

I am not sure what is the right way to actually turn on font-lock by
default, so I didn't do that. (I think there are some subtleties
involving turning on global-font-lock-mode because it's defined using
defcustom). Can someone who knows how this is supposed to work do
this? 

Thanks
                --dan

Re: Global Font Lock by default

[Romain Francoise]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> I've done the first part of this: add to loadup.el the needed files
> and increazed the puresize so that it does not overflow.

Hmm, have you tested this thoroughly?  Suddenly `font-lock-comment-face'
is bold (on a tty).

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: Global Font Lock by default

[Dan Nicolaescu]

Romain Francoise <romain@orebokech.com> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > > I've done the first part of this: add to loadup.el the needed files
  > > and increazed the puresize so that it does not overflow.
  > 
  > Hmm, have you tested this thoroughly?  Suddenly `font-lock-comment-face'
  > is bold (on a tty).

What kind of tty? I tried Linux console, 8 color xterm and 256 color
xterm and font-lock-comment-face is not bold on any of them... 

Re: Global Font Lock by default

[Romain Francoise]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> What kind of tty? I tried Linux console, 8 color xterm and 256 color
> xterm and font-lock-comment-face is not bold on any of them...

8-color xterm.  I cleaned my tree with maintainer-clean and bootstrapped
again but the problem persists.

I start Emacs with `emacs -q -nw', then do M-x global-font-lock-mode RET.
This makes the text in *scratch* become bold.

| Face: font-lock-comment-face (customize this face)
| Documentation: Font Lock mode face used to highlight comments.
| Defined in `font-lock.el'.
|
|          Family: unspecified
|           Width: unspecified
|          Height: unspecified
|          Weight: bold
|           Slant: italic
|      Foreground: unspecified
|      Background: unspecified
|       Underline: unspecified
|        Overline: unspecified
|  Strike-through: unspecified
|             Box: unspecified
|         Inverse: unspecified
|         Stipple: unspecified
| Font or fontset: nil
|         Inherit: unspecified

ELISP> (display-color-cells)
8
ELISP> (frame-parameter nil 'background-mode)
light
ELISP> (frame-parameter nil 'display-type)
color
ELISP>

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: Global Font Lock by default

[Dan Nicolaescu]

Romain Francoise <romain@orebokech.com> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > > What kind of tty? I tried Linux console, 8 color xterm and 256 color
  > > xterm and font-lock-comment-face is not bold on any of them...
  > 
  > 8-color xterm.  I cleaned my tree with maintainer-clean and bootstrapped
  > again but the problem persists.

I can reproduce the problem after a maintainer-clean and bootstrap
too. 

I think the problem is that font-lock-comment-face gets initialized to
this: 
    (t (:weight bold :slant italic)))
when font-lock is loaded in loadup.el

Later when Emacs is started nothing changes the font-lock-comment-face:
    (((class color) (min-colors 8) (background light))
     )

IMO font-lock-comment-face is missing a default as in the patch
below. 
I am not sure if this is the correct fix, maybe something needs to be
changed in the way faces are initialized. (a few other font-lock-*
faces would need the same treatment).

I am not sure what I should do, should I install this fix or back out
the patch that added font-lock to loadup.el? 


*** font-lock.el	31 Oct 2005 08:29:09 -0800	1.280
--- font-lock.el	31 Oct 2005 12:41:58 -0800	
***************
*** 1678,1684 ****
  ;; But now we do it the custom way.  Note that `defface' will not overwrite any
  ;; faces declared above via `custom-declare-face'.
  (defface font-lock-comment-face
!   '((((class grayscale) (background light))
       (:foreground "DimGray" :weight bold :slant italic))
      (((class grayscale) (background dark))
       (:foreground "LightGray" :weight bold :slant italic))
--- 1678,1685 ----
  ;; But now we do it the custom way.  Note that `defface' will not overwrite any
  ;; faces declared above via `custom-declare-face'.
  (defface font-lock-comment-face
!   '((default :inherit default)
!     (((class grayscale) (background light))
       (:foreground "DimGray" :weight bold :slant italic))
      (((class grayscale) (background dark))
       (:foreground "LightGray" :weight bold :slant italic))

Re: Global Font Lock by default

[Romain Francoise]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> IMO font-lock-comment-face is missing a default as in the patch below.

It's probably the wrong fix -- the face definition appears to work fine
on window-system displays.  What makes it behave differently on ttys?

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: Global Font Lock by default

[Dan Nicolaescu]

Romain Francoise <romain@orebokech.com> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > > IMO font-lock-comment-face is missing a default as in the patch below.
  > 
  > It's probably the wrong fix -- the face definition appears to work fine
  > on window-system displays.  What makes it behave differently on ttys?

It seems that the difference is the fact that on 8 color ttys the face
does not specify any properties.

Try adding the faces test1 and test2 to font-lock.el:

(defface test1
  '((((class color) (min-colors 88))
     (:foreground "Firebrick"))
    (((class color) (min-colors 8))
     (:background "magenta4" :foreground "cyan1"))
    (t (:weight bold :slant italic)))
  "test1"
  :group 'font-lock-highlighting-faces)

(defface test2
  '((((class color) (min-colors 88))
     (:foreground "Firebrick"))
    (((class color) (min-colors 8))
     )
    (t (:weight bold :slant italic)))
  "test2"
  :group 'font-lock-highlighting-faces)

then you can observe that test1 is not bold, but face2 is on an 8
color xterm.

Re: Global Font Lock by default

[Romain Francoise]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> It seems that the difference is the fact that on 8 color ttys the face
> does not specify any properties.

Yes, but the reason why that makes a difference only when font-lock.el
is loaded in a dumped Emacs escapes me...

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: Global Font Lock by default

[Dan Nicolaescu]

Romain Francoise <romain@orebokech.com> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > > It seems that the difference is the fact that on 8 color ttys the face
  > > does not specify any properties.
  > 
  > Yes, but the reason why that makes a difference only when font-lock.el
  > is loaded in a dumped Emacs escapes me...

When dumping this part of the font-lock-comment-face face specification matches:
 (t (:weight bold :slant italic)) so the face is created with bold and
 italic properties.

later at run time face-spec-choose is called this will match: 
"((class color) (min-colors 8) (background light))"
but because it specifies no properties face-spec-set returns 
nil => face-spec-reset-face is not called in face-spec-set => the bold
and italic attributes are kept... 

Is this a corner case that was not exercised until now? Or is this by
design? 

In case this is by design, then a better "fix" would be this: 

*** font-lock.el	31 Oct 2005 08:29:09 -0800	1.280
--- font-lock.el	31 Oct 2005 14:06:07 -0800	
***************
*** 1691,1699 ****
      (((class color) (min-colors 16) (background dark))
       (:foreground "red1"))
      (((class color) (min-colors 8) (background light))
!      )
      (((class color) (min-colors 8) (background dark))
!      )
      (t (:weight bold :slant italic)))
    "Font Lock mode face used to highlight comments."
    :group 'font-lock-highlighting-faces)
--- 1691,1699 ----
      (((class color) (min-colors 16) (background dark))
       (:foreground "red1"))
      (((class color) (min-colors 8) (background light))
!      (:inherit default))
      (((class color) (min-colors 8) (background dark))
!      (:inherit default))
      (t (:weight bold :slant italic)))
    "Font Lock mode face used to highlight comments."
    :group 'font-lock-highlighting-faces)

Re: Global Font Lock by default

[Stefan Monnier]

> !      (:inherit default))

Inheriting from default is rarely what you want to do.  Here it's just
a workaround.  The only case I can think of where it makes sense to inherit
from `default' is in cases where you want this face to override the effects
of other faces, e.g. if you want to override the background color of the
header-line on some part of the header-line text, you can place on that text
a face that inherits from `default'.


        Stefan

Re: Global Font Lock by default

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

  > > !      (:inherit default))
  > 
  > Inheriting from default is rarely what you want to do.  Here it's just
  > a workaround.  

Agreed. Do you think that it is a suitable workaround in this case?

Re: Global Font Lock by default

[Stefan Monnier]

>> > !      (:inherit default))
>> 
>> Inheriting from default is rarely what you want to do.  Here it's just
>> a workaround.  

> Agreed. Do you think that it is a suitable workaround in this case?

We want fixes.  Accept no substitute.


        Stefan

Re: Global Font Lock by default

[Miles Bader]

... and if such a workaround _is_ used, please add a comment
describing it as such (otherwise there's a risk that people reading
the code will get the idea it's an acceptable practice).

-miles
--
Do not taunt Happy Fun Ball.

Re: Global Font Lock by default

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

  > > !      (:inherit default))
  > 
  > Inheriting from default is rarely what you want to do.  Here it's just
  > a workaround.  The only case I can think of where it makes sense to inherit
  > from `default' is in cases where you want this face to override the effects
  > of other faces, e.g. if you want to override the background color of the
  > header-line on some part of the header-line text, you can place on that text
  > a face that inherits from `default'.

How about this as a better workaround?

*** font-lock.el	31 Oct 2005 08:29:09 -0800	1.280
--- font-lock.el	01 Nov 2005 07:05:12 -0800	
***************
*** 1691,1699 ****
      (((class color) (min-colors 16) (background dark))
       (:foreground "red1"))
      (((class color) (min-colors 8) (background light))
!      )
      (((class color) (min-colors 8) (background dark))
!      )
      (t (:weight bold :slant italic)))
    "Font Lock mode face used to highlight comments."
    :group 'font-lock-highlighting-faces)
--- 1691,1701 ----
      (((class color) (min-colors 16) (background dark))
       (:foreground "red1"))
      (((class color) (min-colors 8) (background light))
!      ;; ":foreground nil" is a no-op in this case, but it forces the
!      ;; face to be reset at run time.
!      (:foreground nil))
      (((class color) (min-colors 8) (background dark))
!      (:foreground nil))
      (t (:weight bold :slant italic)))
    "Font Lock mode face used to highlight comments."
    :group 'font-lock-highlighting-faces)

Re: Global Font Lock by default

[Romain Francoise]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> When dumping this part of the font-lock-comment-face face
> specification matches: (t (:weight bold :slant italic)) so the face is
> created with bold and italic properties.

> later at run time face-spec-choose is called this will match:
> "((class color) (min-colors 8) (background light))"
> but because it specifies no properties face-spec-set returns nil =>
> face-spec-reset-face is not called in face-spec-set => the bold and
> italic attributes are kept...

Then perhaps `face-spec-set' should reset the face unconditionally if
there are no properties, instead of doing nothing?

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: Global Font Lock by default

[Richard M. Stallman]

    later at run time face-spec-choose is called this will match: 
    "((class color) (min-colors 8) (background light))"
    but because it specifies no properties face-spec-set returns 
    nil => face-spec-reset-face is not called in face-spec-set => the bold
    and italic attributes are kept... 

That seems to be a bug in the general mechanism.
Any defface should have the same meaning, if preloaded,
as it would have if not preloaded.  In particular,
any fallback option which would not apply at run time
should not ultimately apply when preloaded.

Therefore, either (t (:weight bold :slant italic)) should not
be applied during preload, or it should be overridden at start-up.

Please stop looking for workarounds!  That is not the way
to deal with a bug!  Please try to fix the mechanism to DTRT.

If that proves to be really hard, we could document the flaw
and look for a workaround; but we should not give up on a real'
fix without even trying.

Re: Global Font Lock by default

[Dan Nicolaescu]

"Richard M. Stallman" <rms@gnu.org> writes:

  >     later at run time face-spec-choose is called this will match: 
  >     "((class color) (min-colors 8) (background light))"
  >     but because it specifies no properties face-spec-set returns 
  >     nil => face-spec-reset-face is not called in face-spec-set => the bold
  >     and italic attributes are kept... 
  > 
  > That seems to be a bug in the general mechanism.
  > Any defface should have the same meaning, if preloaded,
  > as it would have if not preloaded.  In particular,
  > any fallback option which would not apply at run time
  > should not ultimately apply when preloaded.
  > 
  > Therefore, either (t (:weight bold :slant italic)) should not
  > be applied during preload, or it should be overridden at start-up.

I think that the patch below to face-spec-set  is the right thing to
do.  
FACE needs to be reset even whe `face-choose-set' returns nil, but 
according to the docstring it should not be reset if SPEC is nil. 


*** faces.el	01 Nov 2005 15:50:50 -0800	1.340
--- faces.el	02 Nov 2005 14:17:35 -0800	
***************
*** 1448,1454 ****
  do it on all frames.  See `defface' for information about SPEC.
  If SPEC is nil, do nothing."
    (let ((attrs (face-spec-choose spec frame)))
!     (when attrs
        (face-spec-reset-face face frame))
      (while attrs
        (let ((attribute (car attrs))
--- 1448,1454 ----
  do it on all frames.  See `defface' for information about SPEC.
  If SPEC is nil, do nothing."
    (let ((attrs (face-spec-choose spec frame)))
!     (when spec
        (face-spec-reset-face face frame))
      (while attrs
        (let ((attribute (car attrs))

Re: Global Font Lock by default

[Eli Zaretskii]

> From: Romain Francoise <romain@orebokech.com>
> Date: Mon, 31 Oct 2005 22:11:54 +0100
> Cc: emacs-devel@gnu.org
> 
> Dan Nicolaescu <dann@ics.uci.edu> writes:
> 
> > IMO font-lock-comment-face is missing a default as in the patch below.
> 
> It's probably the wrong fix -- the face definition appears to work fine
> on window-system displays.  What makes it behave differently on ttys?

I suspect it's different on a tty because the tty color support is not
yet fully set up when Emacs is dumped, and/or because we dump in batch
mode.  Dan, could you please see if that guess is true?

If I'm right, one possible solution is to load font-lock at startup
instead of in loadup.

Btw, whatever solution we decide upon, we should make sure that
invoking Emacs with --colors switch does TRT, even if the argument to
this option is different from the default number of supported colors
(the one in effect at dump time).

Re: Global Font Lock by default

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

  > > From: Romain Francoise <romain@orebokech.com>
  > > Date: Mon, 31 Oct 2005 22:11:54 +0100
  > > Cc: emacs-devel@gnu.org
  > > 
  > > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > > 
  > > > IMO font-lock-comment-face is missing a default as in the patch below.
  > > 
  > > It's probably the wrong fix -- the face definition appears to work fine
  > > on window-system displays.  What makes it behave differently on ttys?
  > 
  > I suspect it's different on a tty because the tty color support is not
  > yet fully set up when Emacs is dumped, and/or because we dump in batch
  > mode.  Dan, could you please see if that guess is true?

No, that's not the issue, it's just the way font-lock-comment-face is
defined (see a detailed explanation elsewhere in the
thread: http://lists.gnu.org/archive/html/emacs-devel/2005-10/msg01785.html)

  > If I'm right, one possible solution is to load font-lock at startup
  > instead of in loadup.

I don't think that would be needed. 



  > Btw, whatever solution we decide upon, we should make sure that
  > invoking Emacs with --colors switch does TRT, even if the argument to
  > this option is different from the default number of supported colors
  > (the one in effect at dump time).

Re: Global Font Lock by default

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

  > Btw, whatever solution we decide upon, we should make sure that
  > invoking Emacs with --colors switch does TRT, even if the argument to
  > this option is different from the default number of supported colors
  > (the one in effect at dump time).

Can you please check if everything works how you want it after we are
done with having global-font-lock-mode on by default? I am not 100%
sure I know what the intended behavior of --color is. 

Re: Global Font Lock by default

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dan Nicolaescu <dann@ics.uci.edu>
> Date: Mon, 31 Oct 2005 22:35:21 -0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>   > Btw, whatever solution we decide upon, we should make sure that
>   > invoking Emacs with --colors switch does TRT, even if the argument to
>   > this option is different from the default number of supported colors
>   > (the one in effect at dump time).
> 
> Can you please check if everything works how you want it after we are
> done with having global-font-lock-mode on by default?

I will try, but I have very little free time these days, so it might
be a while until I get to it.

> I am not 100% sure I know what the intended behavior of --color is.

That could mean that the documentation is not clear enough.  Could you
tell what is unclear in the manual where it describes this option?

Re: Global Font Lock by default

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

  > > Cc: emacs-devel@gnu.org
  > > From: Dan Nicolaescu <dann@ics.uci.edu>
  > > Date: Mon, 31 Oct 2005 22:35:21 -0800
  > > 
  > > Eli Zaretskii <eliz@gnu.org> writes:
  > > 
  > >   > Btw, whatever solution we decide upon, we should make sure that
  > >   > invoking Emacs with --colors switch does TRT, even if the argument to
  > >   > this option is different from the default number of supported colors
  > >   > (the one in effect at dump time).
  > > 
  > > Can you please check if everything works how you want it after we are
  > > done with having global-font-lock-mode on by default?
  > 
  > I will try, but I have very little free time these days, so it might
  > be a while until I get to it.
  > 
  > > I am not 100% sure I know what the intended behavior of --color is.
  > 
  > That could mean that the documentation is not clear enough.  Could you
  > tell what is unclear in the manual where it describes this option?

Looking at it again it might be that there are some (simple) bugs in
the way colors are initialized.

For example: on a 256 colors xterm, what should list-colors-display
show when using --color=8? The same as it would on a 8 color xterm
(and no --color options)?

Re: Global Font Lock by default

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dan Nicolaescu <dann@ics.uci.edu>
> Date: Tue, 01 Nov 2005 12:43:00 -0800
> 
> For example: on a 256 colors xterm, what should list-colors-display
> show when using --color=8? The same as it would on a 8 color xterm
> (and no --color options)?

Yes.

Re: Global Font Lock by default

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

  > > Cc: emacs-devel@gnu.org
  > > From: Dan Nicolaescu <dann@ics.uci.edu>
  > > Date: Tue, 01 Nov 2005 12:43:00 -0800
  > > 
  > > For example: on a 256 colors xterm, what should list-colors-display
  > > show when using --color=8? The same as it would on a 8 color xterm
  > > (and no --color options)?
  > 
  > Yes.

That does not happen right now. The problem is that
xterm-register-default-colors creates (display-color-cells) colors, it
does not take into account the --color parameter. This can be fixed
either in xterm-register-default-colors or in display-color-cells. 
What is the preferable fix? 

Re: Global Font Lock by default

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dan Nicolaescu <dann@ics.uci.edu>
> Date: Tue, 01 Nov 2005 21:46:43 -0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>   > > For example: on a 256 colors xterm, what should list-colors-display
>   > > show when using --color=8? The same as it would on a 8 color xterm
>   > > (and no --color options)?
>   > 
>   > Yes.
> 
> That does not happen right now. The problem is that
> xterm-register-default-colors creates (display-color-cells) colors, it
> does not take into account the --color parameter.

That's very strange, because the code was designed so that
display-color-cells _does_ take --colors into account.  Here's how it
was supposed to work:

  . display-color-cells calls tty-display-color-cells

  . tty-display-color-cells returns the value of TN_max_colors

  . TN_max_colors is modified by term.c:tty_setup_colors

  . tty_setup_colors is called by frame.c:store_frame_param (via
    set_tty_color_mode) when the frame parameters alist includes the
    tty-color-mode parameter

  . When Emacs is invoked with --colors=MODE, the startup code (in
    tty-handle-args) pushes the appropriate tty-color-mode parameter
    into the alist

Which part of this isn't working, and why?

> This can be fixed either in xterm-register-default-colors or in
> display-color-cells.  What is the preferable fix?

I cannot answer this without understanding the problem.  The fix
should be where the bug lurks, in general.

Re: Global Font Lock by default

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

  > > Cc: emacs-devel@gnu.org
  > > From: Dan Nicolaescu <dann@ics.uci.edu>
  > > Date: Tue, 01 Nov 2005 21:46:43 -0800
  > > 
  > > Eli Zaretskii <eliz@gnu.org> writes:
  > > 
  > >   > > For example: on a 256 colors xterm, what should list-colors-display
  > >   > > show when using --color=8? The same as it would on a 8 color xterm
  > >   > > (and no --color options)?
  > >   > 
  > >   > Yes.
  > > 
  > > That does not happen right now. The problem is that
  > > xterm-register-default-colors creates (display-color-cells) colors, it
  > > does not take into account the --color parameter.

Ooops, this is a bit more convoluted than I believed... 

  > That's very strange, because the code was designed so that
  > display-color-cells _does_ take --colors into account.  Here's how it
  > was supposed to work:
  > 
  >   . display-color-cells calls tty-display-color-cells
  > 
  >   . tty-display-color-cells returns the value of TN_max_colors
  > 
  >   . TN_max_colors is modified by term.c:tty_setup_colors
  > 
  >   . tty_setup_colors is called by frame.c:store_frame_param (via
  >     set_tty_color_mode) when the frame parameters alist includes the
  >     tty-color-mode parameter

(assume a 256 colors xterm)
One problem is here:
tty_setup_colors does not do anything with its argument (mode) if for
example mode is 16 (i.e. when using --color=16)

Another problem: when using --color=8, display-color-cells will return
8 after emacs is started, but when xterm-register-default-colors is
run it returns 256 ... 

Re: Global Font Lock by default

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dan Nicolaescu <dann@ics.uci.edu>
> Date: Wed, 02 Nov 2005 12:00:53 -0800
> 
> (assume a 256 colors xterm)
> One problem is here:
> tty_setup_colors does not do anything with its argument (mode) if for
> example mode is 16 (i.e. when using --color=16)

This is not a bug: 16 colors is not a standard color mode, so it is
not currently supported (the manual explains that, I hope).

> Another problem: when using --color=8, display-color-cells will return
> 8 after emacs is started, but when xterm-register-default-colors is
> run it returns 256 ... 

This is a bug: when Emacs is started with --color=8, it should behave
as if only the 8 standard colors are available.  Could you please see
what changes the value returned by display-color-cells?  Something is
calling tty_setup_colors to reset to the default color mode (the one
that supports 256 colors).

TIA

Re: Global Font Lock by default

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

  > > Cc: emacs-devel@gnu.org
  > > From: Dan Nicolaescu <dann@ics.uci.edu>
  > > Date: Wed, 02 Nov 2005 12:00:53 -0800
  > > 
  > > (assume a 256 colors xterm)
  > > One problem is here:
  > > tty_setup_colors does not do anything with its argument (mode) if for
  > > example mode is 16 (i.e. when using --color=16)
  > 
  > This is not a bug: 16 colors is not a standard color mode, so it is
  > not currently supported (the manual explains that, I hope).

The manual says "... 8, 16, 88, or 256 as the value of NUM"

  > > Another problem: when using --color=8, display-color-cells will return
  > > 8 after emacs is started, but when xterm-register-default-colors is
  > > run it returns 256 ... 
  > 
  > This is a bug: when Emacs is started with --color=8, it should behave
  > as if only the 8 standard colors are available.  Could you please see
  > what changes the value returned by display-color-cells?  Something is
  > calling tty_setup_colors to reset to the default color mode (the one
  > that supports 256 colors).

Nothing tries to reset to the default color mode, it looks like
xterm-register-default-colors is called before tty_setup_colors,
so display-color-cells returns the default 256.

When set_tty_color_mode is called:
(gdb) xbacktrace 
"modify-frame-parameters"
"frame-notice-user-settings"
"command-line-1"
"command-line"
"normal-top-level"

if you look in `command-line', the call to  `command-line-1' is a
few lines after the code that loads the term/xterm.el file.

Re: Global Font Lock by default

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dan Nicolaescu <dann@ics.uci.edu>
> Date: Wed, 02 Nov 2005 21:53:10 -0800
> 
>   > > (assume a 256 colors xterm)
>   > > One problem is here:
>   > > tty_setup_colors does not do anything with its argument (mode) if for
>   > > example mode is 16 (i.e. when using --color=16)
>   > 
>   > This is not a bug: 16 colors is not a standard color mode, so it is
>   > not currently supported (the manual explains that, I hope).
> 
> The manual says "... 8, 16, 88, or 256 as the value of NUM"

This probably means it did work when I wrote the code and the
documentation, and I just forgot.  Sorry for the confusion, it's been
a long time since I looked at the code.

>   > > Another problem: when using --color=8, display-color-cells will return
>   > > 8 after emacs is started, but when xterm-register-default-colors is
>   > > run it returns 256 ... 
>   > 
>   > This is a bug: when Emacs is started with --color=8, it should behave
>   > as if only the 8 standard colors are available.  Could you please see
>   > what changes the value returned by display-color-cells?  Something is
>   > calling tty_setup_colors to reset to the default color mode (the one
>   > that supports 256 colors).
> 
> Nothing tries to reset to the default color mode, it looks like
> xterm-register-default-colors is called before tty_setup_colors,
> so display-color-cells returns the default 256.
> 
> When set_tty_color_mode is called:
> (gdb) xbacktrace 
> "modify-frame-parameters"
> "frame-notice-user-settings"
> "command-line-1"
> "command-line"
> "normal-top-level"
> 
> if you look in `command-line', the call to  `command-line-1' is a
> few lines after the code that loads the term/xterm.el file.

This does not necessarily constitute a bug: the terminal file should
indeed be loaded before --color is processed.  That's because the
terminal file defines the default color mode, and the user needs to be
able to return to that default during the session by adding
`(tty-color-mode 0)' to the frame's parameters.

So I'd expect display-color-cells to return 256 before --color=8 is
processed by startup.el, but 8 after it processes --color=8.

I don't know when I will have time to work on this, so if you (or
someone else) want to try, please go ahead.  I'll try to help as well
as I can.

TIA

Re: Global Font Lock by default

[Eli Zaretskii]

> Date: Fri, 04 Nov 2005 13:01:32 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > The manual says "... 8, 16, 88, or 256 as the value of NUM"
> 
> This probably means it did work when I wrote the code and the
> documentation, and I just forgot.  Sorry for the confusion, it's been
> a long time since I looked at the code.

Actually, now that I think about it, --color=256 is only supposed to
work if the default number of colors (the one mentioned in the
terminfo entry) for this terminal is 256.

Re: Global Font Lock by default

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

  > > I am not 100% sure I know what the intended behavior of --color is.
  > 
  > That could mean that the documentation is not clear enough.  Could you
  > tell what is unclear in the manual where it describes this option?

The parts that describe the "no", "default" and "ansi8" options are
clear. 

This part:

    `NUM'
          Use color mode for NUM colors.  If NUM is -1, turn off color
          support (equivalent to `never'); if it is 0, use the default
          color support for this terminal (equivalent to `auto');
          otherwise use an appropriate standard mode for NUM colors.
          Depending on your terminal's capabilities, Emacs might be
          able to turn on a color mode for 8, 16, 88, or 256 as the
          value of NUM.  If there is no mode that supports NUM colors,
          Emacs acts as if NUM were 0, i.e. it uses the terminal's
          default color support mode.
     If MODE is omitted, it defaults to ANSI8.

is a bit unclear.

One thing that is missing is stating the the point of this option. Why
would a user want to use it? (some use-cases would be helpful).

The meaning of "If there is no mode that supports NUM colors" is
unclear. How is this "support" determined? (For example
if terminfo says colors#256, does that mean that --color=88 is
supported? How about 16 or 8 ?)

As I said I am not sure what the intended behavior is, so I can't
"fix" the docs myself.

      --dan

Re: Global Font Lock by default

[Dan Nicolaescu]

Dan Nicolaescu <dann@ics.uci.edu> writes:

  > "Richard M. Stallman" <rms@gnu.org> writes:
  > 
  >   > So now I think we are ready to enable font-lock by default.
  >   > Would someone like to do that?
  > 
  > I've done the first part of this: add to loadup.el the needed files
  > and increazed the puresize so that it does not overflow. 
  > 
  > I am not sure what is the right way to actually turn on font-lock by
  > default, so I didn't do that. (I think there are some subtleties
  > involving turning on global-font-lock-mode because it's defined using
  > defcustom). Can someone who knows how this is supposed to work do
  > this? 

Well, this patch seems to give good results in all my tests: 

*** loadup.el	31 Oct 2005 08:36:02 -0800	1.143
--- loadup.el	31 Oct 2005 23:21:16 -0800	
***************
*** 209,214 ****
--- 209,216 ----
  (load "ediff-hook")
  (if (fboundp 'x-show-tip) (load "tooltip"))
  
+ (global-font-lock-mode t)
+ (customize-mark-as-set 'global-font-lock-mode)
  (message "%s" (garbage-collect))
  
  ;If you want additional libraries to be preloaded and their


Should I check it in? 

(BTW auto-compression-mode also seems to need a customize-mark-as-set)

Re: Global Font Lock by default

[Kim F. Storm]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> Well, this patch seems to give good results in all my tests: 
>
> *** loadup.el	31 Oct 2005 08:36:02 -0800	1.143
> --- loadup.el	31 Oct 2005 23:21:16 -0800	
> ***************
> *** 209,214 ****
> --- 209,216 ----
>   (load "ediff-hook")
>   (if (fboundp 'x-show-tip) (load "tooltip"))
>   
> + (global-font-lock-mode t)
> + (customize-mark-as-set 'global-font-lock-mode)
>   (message "%s" (garbage-collect))
>   
>   ;If you want additional libraries to be preloaded and their

Maybe we should have a --no-font-lock -nfl options....


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Global Font Lock by default

[Kim F. Storm]

storm@cua.dk (Kim F. Storm) writes:

> Dan Nicolaescu <dann@ics.uci.edu> writes:
>
>> Well, this patch seems to give good results in all my tests: 
>>
>> *** loadup.el	31 Oct 2005 08:36:02 -0800	1.143
>> --- loadup.el	31 Oct 2005 23:21:16 -0800	
>> ***************
>> *** 209,214 ****
>> --- 209,216 ----
>>   (load "ediff-hook")
>>   (if (fboundp 'x-show-tip) (load "tooltip"))
>>   
>> + (global-font-lock-mode t)
>> + (customize-mark-as-set 'global-font-lock-mode)
>>   (message "%s" (garbage-collect))
>>   
>>   ;If you want additional libraries to be preloaded and their
>
> Maybe we should have a --no-font-lock -nfl options....

And it should definitely not be enabled if you use -D option.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Global Font Lock by default

[Chong Yidong]

>> Maybe we should have a --no-font-lock -nfl options....
>
> And it should definitely not be enabled if you use -D option.

Why not just turn off font-lock when -D is on?

Re: Global Font Lock by default

[Kim F. Storm]

Chong Yidong <cyd@stupidchicken.com> writes:

>>> Maybe we should have a --no-font-lock -nfl options....
>>
>> And it should definitely not be enabled if you use -D option.
>
> Why not just turn off font-lock when -D is on?

Can it be more simple than this:

(unless inhibit-global-font-lock
  (global-font-lock-mode t)
  (customize-mark-as-set 'global-font-lock-mode))

provided that startup.el sets inhibit-global-font-lock 
if -nfl or -no-font-lock is present,
or emacs-basic-display (-D) is true.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Global Font Lock by default

[Dan Nicolaescu]

storm@cua.dk (Kim F. Storm) writes:

  > Chong Yidong <cyd@stupidchicken.com> writes:
  > 
  > >>> Maybe we should have a --no-font-lock -nfl options....
  > >>
  > >> And it should definitely not be enabled if you use -D option.
  > >
  > > Why not just turn off font-lock when -D is on?
  > 
  > Can it be more simple than this:
  > 
  > (unless inhibit-global-font-lock
  >   (global-font-lock-mode t)
  >   (customize-mark-as-set 'global-font-lock-mode))

Both versions should work, it's just a matter of deciding when is
better to turn on global-font-lock-mode: at run time or at dump time.
Opinions? 

(I'm inclined to believe is better to do as much work as possible at
dump time)

Re: Global Font Lock by default

[Luc Teirlinck]

Kim Storm wrote:

   Both versions should work, it's just a matter of deciding when is
   better to turn on global-font-lock-mode: at run time or at dump time.
   Opinions? 

   (I'm inclined to believe is better to do as much work as possible at
   dump time)

I have not yet had the time to look at this in full detail, but I do
not believe that any of these two versions will work.  I believe that
both will give problems when the user selects "Erase Customization" in
a custom buffer.  I believe that the correct way to this is to pass

:initialize 'custom-initialize-safe-default

and the desired :initial value to the `easy-mmode-define-global-mode'
call at the end of "font-core.el".  The :initial-value should be set
to the exact default, given initial options and the like.  "font-core"
is loaded before startup, but custom-initialize-safe-default will
prevent the :init-value to be executed at that stage, so you do not
need to worry about variables used in the :init-value not yet being
defined then.  Then you do

(custom-reevaluate-setting 'global-font-lock-mode)

in startup.el.  This will execute the :init-value when all the initial
options and stuff are known.

Sincerely,

Luc.

Re: Global Font Lock by default

[Luc Teirlinck]

>From my previous message:

   The :initial-value should be set to the exact default,

I misspelled this a few times.  The correct keyword is `:init-value'.

Sincerely,

Luc.

Re: Global Font Lock by default

[Luc Teirlinck]

>From my previous message:

   Kim Storm wrote:

      Both versions should work, it's just a matter of deciding when is
      better to turn on global-font-lock-mode: at run time or at dump time.
      Opinions? 

      (I'm inclined to believe is better to do as much work as possible at
      dump time)

I was quoting the wrong person again, Dan Nicolaescu wrote the above quote.

Sincerely,

Luc.

Re: Global Font Lock by default

[Eli Zaretskii]

> From: Dan Nicolaescu <dann@ics.uci.edu>
> Date: Tue, 01 Nov 2005 07:10:07 -0800
> Cc: Chong Yidong <cyd@stupidchicken.com>, emacs-devel@gnu.org
> 
> Both versions should work, it's just a matter of deciding when is
> better to turn on global-font-lock-mode: at run time or at dump time.
> Opinions? 

My preference is to turn it on at startup time (however, you can load
it at dump time).  There's no sense in using colors at dump time, and
doing so might even do harm if the color-related environment changes
between dump and startup time.

> (I'm inclined to believe is better to do as much work as possible at
> dump time)

In this case, this extra work is useless, IMHO.

Re: Global Font Lock by default

[Eli Zaretskii]

> From: storm@cua.dk (Kim F. Storm)
> Date: Tue, 01 Nov 2005 11:03:41 +0100
> Cc: emacs-devel@gnu.org
> 
> Maybe we should have a --no-font-lock -nfl options....

What for?  What's wrong with disabling it in one's ~/.emacs?

Re: Global Font Lock by default

[Kim F. Storm]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: storm@cua.dk (Kim F. Storm)
>> Date: Tue, 01 Nov 2005 11:03:41 +0100
>> Cc: emacs-devel@gnu.org
>> 
>> Maybe we should have a --no-font-lock -nfl options....
>
> What for?  What's wrong with disabling it in one's ~/.emacs?

So you can disable it together with -q.

But as long as -D disables it, I don't care much.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Global Font Lock by default

[Luc Teirlinck]

Here are patches that will enable global-font-lock-mode by default
unless the -D option was specified or unless Emacs is running in batch
mode (but they provide no --no-font-lock or -nfl options).  Unlike
previous proposals, they should create no problems with Custom.  This
requires a change to `define-global-minor-mode'.  Unlike at present,
after my patch to easy-mmode.el, `define-global-minor-mode' will pass
_all_ provided keywords to `define-minor-mode'.  This is necessary for
the defcustom, as the present situation shows.

I can install if desired.

===File ~/easy-mmode-diff===================================
*** easy-mmode.el	24 Aug 2005 08:06:37 -0500	1.71
--- easy-mmode.el	01 Nov 2005 17:39:25 -0600	
***************
*** 285,305 ****
  	 (pretty-name (easy-mmode-pretty-mode-name mode))
  	 (pretty-global-name (easy-mmode-pretty-mode-name global-mode))
  	 (group nil)
! 	 (extra-args nil)
  	 (MODE-buffers (intern (concat global-mode-name "-buffers")))
  	 (MODE-enable-in-buffers
  	  (intern (concat global-mode-name "-enable-in-buffers")))
  	 (MODE-check-buffers
  	  (intern (concat global-mode-name "-check-buffers")))
  	 (MODE-cmhh (intern (concat global-mode-name "-cmhh")))
! 	 (MODE-major-mode (intern (concat (symbol-name mode) "-major-mode"))))
  
      ;; Check keys.
!     (while (keywordp (car keys))
!       (case (pop keys)
! 	(:extra-args (setq extra-args (pop keys)))
  	(:group (setq group (nconc group (list :group (pop keys)))))
! 	(t (setq keys (cdr keys)))))
  
      (unless group
        ;; We might as well provide a best-guess default group.
--- 285,306 ----
  	 (pretty-name (easy-mmode-pretty-mode-name mode))
  	 (pretty-global-name (easy-mmode-pretty-mode-name global-mode))
  	 (group nil)
! 	 (extra-keywords nil)
  	 (MODE-buffers (intern (concat global-mode-name "-buffers")))
  	 (MODE-enable-in-buffers
  	  (intern (concat global-mode-name "-enable-in-buffers")))
  	 (MODE-check-buffers
  	  (intern (concat global-mode-name "-check-buffers")))
  	 (MODE-cmhh (intern (concat global-mode-name "-cmhh")))
! 	 (MODE-major-mode (intern (concat (symbol-name mode) "-major-mode")))
! 	 keyw)
  
      ;; Check keys.
!     (while (keywordp (setq keyw (car keys)))
!       (setq keys (cdr keys))
!       (case keyw
  	(:group (setq group (nconc group (list :group (pop keys)))))
! 	(t (push keyw extra-keywords) (push (pop keys) extra-keywords))))
  
      (unless group
        ;; We might as well provide a best-guess default group.
***************
*** 317,323 ****
  %s is actually not turned on in every buffer but only in those
  in which `%s' turns it on."
  		  pretty-name pretty-global-name pretty-name turn-on)
! 	 :global t :extra-args ,extra-args ,@group
  
  	 ;; Setup hook to handle future mode changes and new buffers.
  	 (if ,global-mode
--- 318,324 ----
  %s is actually not turned on in every buffer but only in those
  in which `%s' turns it on."
  		  pretty-name pretty-global-name pretty-name turn-on)
! 	 :global t ,@group ,@(nreverse extra-keywords)
  
  	 ;; Setup hook to handle future mode changes and new buffers.
  	 (if ,global-mode
============================================================

===File ~/font-core-diff====================================
*** font-core.el	20 Oct 2005 08:28:35 -0500	1.33
--- font-core.el	01 Nov 2005 17:29:48 -0600	
***************
*** 293,299 ****
  
  (easy-mmode-define-global-mode
   global-font-lock-mode font-lock-mode turn-on-font-lock-if-enabled
!  :extra-args (dummy))
  
  ;;; End of Global Font Lock mode.
  
--- 293,301 ----
  
  (easy-mmode-define-global-mode
   global-font-lock-mode font-lock-mode turn-on-font-lock-if-enabled
!  :extra-args (dummy)
!  :initialize 'custom-initialize-safe-default
!  :init-value (not (or noninteractive emacs-basic-display)))
  
  ;;; End of Global Font Lock mode.
  
============================================================

===File ~/startup-diff======================================
*** startup.el	30 Oct 2005 08:25:09 -0600	1.383
--- startup.el	01 Nov 2005 17:29:28 -0600	
***************
*** 765,770 ****
--- 765,771 ----
    (custom-reevaluate-setting 'blink-cursor-mode)
    (custom-reevaluate-setting 'normal-erase-is-backspace)
    (custom-reevaluate-setting 'tooltip-mode)
+   (custom-reevaluate-setting 'global-font-lock-mode)
  
    ;; Register default TTY colors for the case the terminal hasn't a
    ;; terminal init file.
============================================================

Re: Global Font Lock by default

[Richard M. Stallman]

    Maybe we should have a --no-font-lock -nfl options....

I don't see a need for them.  There is no reason to make
a command line option for every Emacs option.
Command line options are mainly useful for things
that you might want to do differently from one Emacs invocation
to another.  I don't think that font lock is in that class.

Besides, people will think that -nfl means it follows
US-style football rules.

Re: Global Font Lock by default

[David Kastrup]

"Richard M. Stallman" <rms@gnu.org> writes:

>     Maybe we should have a --no-font-lock -nfl options....
>
> I don't see a need for them.  There is no reason to make
> a command line option for every Emacs option.
> Command line options are mainly useful for things
> that you might want to do differently from one Emacs invocation
> to another.  I don't think that font lock is in that class.

One might want to open a file that has serious performance issues or
other problems in font lock mode.

Also, I think that for -batch, it does not make sense to have font
lock enabled.

> Besides, people will think that -nfl means it follows
> US-style football rules.

And we all know that Emacs is currently quite more than a quarterback.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Global Font Lock by default

[Luc Teirlinck]

David Kastrup wrote:

   Also, I think that for -batch, it does not make sense to have font
   lock enabled.

It will not be enabled for -batch (nor for -D) if we apply my patches.

Sincerely,

Luc.

Re: Global Font Lock by default

[Richard M. Stallman]

    Also, I think that for -batch, it does not make sense to have font
    lock enabled.

I agree with that.  So --batch, like -D, should turn it off.  But I
don't see a need for -nfl.  You may want to edit a certain file
without font lock, but why would you start a new Emacs to do that?
The way to do that is to visit it and then type M-x font-lock-mode.

Re: Global Font Lock by default

[Stefan Monnier]

>     Also, I think that for -batch, it does not make sense to have font
>     lock enabled.

If you look at the font-lock-mode function's definition you'll see that it
is already conditional on the value of `interactive'.
So even if you turn on global-font-lock-mode with -batch, none of the
buffers will be put in font-lock-mode.


        Stefan

Re: Global Font Lock by default

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>     Also, I think that for -batch, it does not make sense to have font
>>     lock enabled.
>
> If you look at the font-lock-mode function's definition you'll see
> that it is already conditional on the value of `interactive'.  So
> even if you turn on global-font-lock-mode with -batch, none of the
> buffers will be put in font-lock-mode.

Ah, ok.  No offense intended.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Global Font Lock by default

[Luc Teirlinck]

Below is a slightly revised version of my patch to easy-mmode.  The
only differences with my prior patch are that the new treatment of
keywords is now reflected in the docstring and that a :global keyword
is now ignored, since the very use of `define-global-minor-mode'
implies that it must be t.  If my patches seem OK, I would also update
the Elisp doc for `define-global-minor-mode'.

===File ~/easy-mmode-diff===================================
*** easy-mmode.el	24 Aug 2005 08:06:37 -0500	1.71
--- easy-mmode.el	03 Nov 2005 19:04:26 -0600	
***************
*** 272,279 ****
    "Make GLOBAL-MODE out of the buffer-local minor MODE.
  TURN-ON is a function that will be called with no args in every buffer
    and that should try to turn MODE on if applicable for that buffer.
! KEYS is a list of CL-style keyword arguments:
! :group to specify the custom group.
  
  If MODE's set-up depends on the major mode in effect when it was
  enabled, then disabling and reenabling MODE should make MODE work
--- 272,285 ----
    "Make GLOBAL-MODE out of the buffer-local minor MODE.
  TURN-ON is a function that will be called with no args in every buffer
    and that should try to turn MODE on if applicable for that buffer.
! KEYS is a list of CL-style keyword arguments.  As the minor mode
!   defined by this function is always global, any :global keyword is
!   ignored.  Other keywords have the same meaning as in `define-minor-mode',
!   which see.  In particular, :group specifies the custom group.
!   The most useful keywords are those that are passed on to the
!   `defcustom'.  It normally makes no sense to pass the :lighter
!   or :keymap keywords to `define-global-minor-mode', since these
!   are usually passed to the buffer-local version of the minor mode.
  
  If MODE's set-up depends on the major mode in effect when it was
  enabled, then disabling and reenabling MODE should make MODE work
***************
*** 285,305 ****
  	 (pretty-name (easy-mmode-pretty-mode-name mode))
  	 (pretty-global-name (easy-mmode-pretty-mode-name global-mode))
  	 (group nil)
! 	 (extra-args nil)
  	 (MODE-buffers (intern (concat global-mode-name "-buffers")))
  	 (MODE-enable-in-buffers
  	  (intern (concat global-mode-name "-enable-in-buffers")))
  	 (MODE-check-buffers
  	  (intern (concat global-mode-name "-check-buffers")))
  	 (MODE-cmhh (intern (concat global-mode-name "-cmhh")))
! 	 (MODE-major-mode (intern (concat (symbol-name mode) "-major-mode"))))
  
      ;; Check keys.
!     (while (keywordp (car keys))
!       (case (pop keys)
! 	(:extra-args (setq extra-args (pop keys)))
  	(:group (setq group (nconc group (list :group (pop keys)))))
! 	(t (setq keys (cdr keys)))))
  
      (unless group
        ;; We might as well provide a best-guess default group.
--- 291,313 ----
  	 (pretty-name (easy-mmode-pretty-mode-name mode))
  	 (pretty-global-name (easy-mmode-pretty-mode-name global-mode))
  	 (group nil)
! 	 (extra-keywords nil)
  	 (MODE-buffers (intern (concat global-mode-name "-buffers")))
  	 (MODE-enable-in-buffers
  	  (intern (concat global-mode-name "-enable-in-buffers")))
  	 (MODE-check-buffers
  	  (intern (concat global-mode-name "-check-buffers")))
  	 (MODE-cmhh (intern (concat global-mode-name "-cmhh")))
! 	 (MODE-major-mode (intern (concat (symbol-name mode) "-major-mode")))
! 	 keyw)
  
      ;; Check keys.
!     (while (keywordp (setq keyw (car keys)))
!       (setq keys (cdr keys))
!       (case keyw
  	(:group (setq group (nconc group (list :group (pop keys)))))
! 	(:global (setq keys (cdr keys)))
! 	(t (push keyw extra-keywords) (push (pop keys) extra-keywords))))
  
      (unless group
        ;; We might as well provide a best-guess default group.
***************
*** 317,323 ****
  %s is actually not turned on in every buffer but only in those
  in which `%s' turns it on."
  		  pretty-name pretty-global-name pretty-name turn-on)
! 	 :global t :extra-args ,extra-args ,@group
  
  	 ;; Setup hook to handle future mode changes and new buffers.
  	 (if ,global-mode
--- 325,331 ----
  %s is actually not turned on in every buffer but only in those
  in which `%s' turns it on."
  		  pretty-name pretty-global-name pretty-name turn-on)
! 	 :global t ,@group ,@(nreverse extra-keywords)
  
  	 ;; Setup hook to handle future mode changes and new buffers.
  	 (if ,global-mode
============================================================