Re: [PATCH] Remove obsolete fast-lock and lazy-lock libraries

[Jeff Norden]

> I see no particular reason to rename the variable, just because it
> currently has only one user (inside the core).  It's not like adding
> other users is unimaginable, and renaming is always a certain shock,
> however small.
>
>> It might make sense to also drop the defcustom status of the support-mode
>> variable (or its replacement), since jit-lock is the only non-nil option.
>
> Likewise here: we have many options that have just 2 values, and they
> are still defcustom's.

I was thinking that a more descriptive name would make it easier for
people to figure out what the variable is for.  But, your point that
changing the name might be disruptive certainly valid.  Maybe re-writing
the docstring would be a better solution.  How about something like:

----------
(defcustom font-lock-support-mode 't
  "If non-nil, use `jit-lock-mode' to support fast fontification by being
choosy about when fontification occurs.

If nil, Jit Lock is never used.  This may be helpful for debugging.
To avoid long delays, only buffers smaller than `font-lock-maximum-size'
will be fontified.

If a list, each element should be of the form (MAJOR-MODE . VALUE),
where MAJOR-MODE is a symbol or t (meaning the default).  For example:
 ((c-mode . nil) (t . t))
means that Jit Lock is used by default, but C mode buffers will be
fontified without support.

The value of this variable is used when Font Lock mode is turned on.

Historically, this variable was used to choose between several possible
methods of accelerated fontification.  As of nn.n, Jit Lock is the only
method that is supported."
----------

I do think a default value of t is a better choice than 'jit-lock-mode, since
it doesn't give the impression that there are other possible values.  Whether
it should still be defcustom is something that you are in a better position to
judge than I am.  My thought was that it would now be mainly for debugging.
Turning it off will cause large buffers to be un-fontified and/or might
result in long delays.

Also, I think there was a typo in Stefan's patch where it says

 + ((c-mode . nil) (t . jit-lock-mode))
 +means that no font locking is used for buffers in C

If I'm understanding correctly, c-mode will still have font locking, but
without jit lock.

Thanks,
-Jeff