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

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

[Stefan Monnier]

>> There are also these two libraries:
>> ./lisp/obsolete/fast-lock.el9:;; Obsolete-since: 22.1
>> ./lisp/obsolete/lazy-lock.el9:;; Obsolete-since: 22.1
> I have attached a patch to remove them below.

LGTM.

>  ;; to avoid compilation gripes
>  (defun ps-print-ensure-fontified (start end)
>    (cond ((and (boundp 'jit-lock-mode) (symbol-value 'jit-lock-mode))
> -	 (jit-lock-fontify-now start end))
> -	((and (boundp 'lazy-lock-mode) (symbol-value 'lazy-lock-mode))
> -	 (lazy-lock-fontify-region start end))))
> +	 (jit-lock-fontify-now start end))))

I think this can be replaced by `font-lock-ensure`, but it probably
requires additional tests to be sure, so maybe keep the code as is and
just add a FIXME.


        Stefan

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

[Jeff Norden]

> One thing to note is that I've kept the support for
> 'font-lock-support-mode' set to nil since Alan Mackenzie indicated
> that this could be useful for debugging purposes here:
>   https://lists.gnu.org/archive/html/emacs-devel/2011-10/msg00748.html
> Perhaps it should be changed into a defvar, though. Or maybe it is no
> longer useful. But that could in any case be done separately, I think.

I discovered (setq font-lock-support-mode nil) just a few weeks ago, and
found it to be a helpful tool for debugging fontification code.  It
simplifies things by letting you temporarily take the jit-lock layer
entirely out of the picture.  Once things are working without jit, you
can then use jit-lock-debug-mode to further narrow down issues.

A variable name like font-lock-use-jit might be more clear, maybe with
font-lock-support-mode as an obsolete alias, which would now only have a
nil-or-non-nil effect.  Perhaps this would be good to do along with 
removing {fast,lazy}-lock.  If someone has an ancient .emacs that contains
  (setq font-lock-support-mode 'fast-lock-mode)
would the best thing be to just use jit-lock-mode instead?  If I'm reading
the patch correctly, it would make setting the support-mode to fast-lock
equivalent to setting it to nil.

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.
Things can still be pretty slow without jit, despite comments in the 2011 post
that is referenced above.  On my computer (a relatively current intel i5),
fontifying all of xdisp.c (1.1MB) takes about 8.3 sec with the default c-mode.
This could become a problem when font-lock-maximum-size goes away.
(I got this time by setting font-lock-support-mode to nil, opening
xdisp.c, which is now un-fontified b/c of its size, and then 'M-x benchmark'
followed by (font-lock-fontify-buffer)).

-Jeff 

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

[Eli Zaretskii]

> From: Jeff Norden <jnorden@tntech.edu>
> Date: Sat, 08 Aug 2020 23:04:42 -0500
> Cc: stefankangas@gmail.com, monnier@iro.umontreal.ca
> 
> A variable name like font-lock-use-jit might be more clear, maybe with
> font-lock-support-mode as an obsolete alias, which would now only have a
> nil-or-non-nil effect.  Perhaps this would be good to do along with 
> removing {fast,lazy}-lock.  If someone has an ancient .emacs that contains
>   (setq font-lock-support-mode 'fast-lock-mode)
> would the best thing be to just use jit-lock-mode instead?  If I'm reading
> the patch correctly, it would make setting the support-mode to fast-lock
> equivalent to setting it to nil.

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.

In general, such cleanups are IMO only justified if they bring some
real advantages, or if the variables are no longer used at all.  This
is not such a case.

Thanks.

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

[Stefan Kangas]

Jeff Norden <jnorden@tntech.edu> writes:

>                             If someone has an ancient .emacs that contains
>   (setq font-lock-support-mode 'fast-lock-mode)
> would the best thing be to just use jit-lock-mode instead?  If I'm reading
> the patch correctly, it would make setting the support-mode to fast-lock
> equivalent to setting it to nil.

Sure, that makes sense. I could change that before pushing.

Best regards,
Stefan Kangas

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

[Alan Mackenzie]

Hello, Stefan.

On Sun, Aug 09, 2020 at 09:28:47 -0700, Stefan Kangas wrote:
> Jeff Norden <jnorden@tntech.edu> writes:

> >                             If someone has an ancient .emacs that contains
> >   (setq font-lock-support-mode 'fast-lock-mode)
> > would the best thing be to just use jit-lock-mode instead?  If I'm reading
> > the patch correctly, it would make setting the support-mode to fast-lock
> > equivalent to setting it to nil.

> Sure, that makes sense. I could change that before pushing.

This doesn't make sense, I think.  font-lock-support-mode is a function,
and if a user has this set to a non-existent function, the correct
response is surely to tell her with an error message, rather than
executing a different function.

The only reason anybody nowadays would set f-l-s-m to 'fast-lock-mode
would be for debugging.  Let's not make that debugging any more
difficult than it already is.

> Best regards,
> Stefan Kangas

-- 
Alan Mackenzie (Nuremberg, Germany).

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

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

[Stefan Monnier]

> I was thinking that a more descriptive name would make it easier for
> people to figure out what the variable is for.

IMNSHO, that variable should not be a defcustom any more and we
shouldn't encourage users to touch it.  IOW we should mark it obsolete.

We could OTOH add a new command to enter a form of
`font-lock-debug-mode` which could disable the use of jit-lock (but not
necessarily in exactly the same way as setting `font-lock-support-mode`
would, tho it would probably be the most obvious immediate choice in the
short term).


        Stefan

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

[Stefan Kangas]

Hi Alan,

Alan Mackenzie <acm@muc.de> writes:

> > >                             If someone has an ancient .emacs that contains
> > >   (setq font-lock-support-mode 'fast-lock-mode)
> > > would the best thing be to just use jit-lock-mode instead?  If I'm reading
> > > the patch correctly, it would make setting the support-mode to fast-lock
> > > equivalent to setting it to nil.
>
> > Sure, that makes sense. I could change that before pushing.
>
> This doesn't make sense, I think.  font-lock-support-mode is a function,
> and if a user has this set to a non-existent function, the correct
> response is surely to tell her with an error message, rather than
> executing a different function.

Okay, that's a fair point. But if the user has set it to lazy-lock or
fast-lock wouldn't the reason most likely be that it's expected to be
better for normal use? And, if that holds, shouldn't we be a bit
forthcoming by just using the current best, which is jit-lock?

OTOH, I guess that for any other value it is probably best to signal
an error rather than silently defaulting to nil.

Still, I don't have any strong feelings either way. If the consensus
is to signal an error for any other value than jit-lock and nil, I'm
perfectly fine with that too.

Best regards,
Stefan Kangas

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

[Stefan Monnier]

> Okay, that's a fair point. But if the user has set it to lazy-lock or
> fast-lock wouldn't the reason most likely be that it's expected to be
> better for normal use? And, if that holds, shouldn't we be a bit
> forthcoming by just using the current best, which is jit-lock?
>
> OTOH, I guess that for any other value it is probably best to signal
> an error rather than silently defaulting to nil.
>
> Still, I don't have any strong feelings either way.

I have no reason to believe that there's a non-negligible number of
users out there in the wild using fast-lock or lazy-lock, so whether we
ignore such settings or signal an error for them probably won't make much
difference either way.  I guess the nicer way is to ignore the setting
but emit a message, if you really care.


        Stefan

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

[Jeff Norden]

Alan Mackenzie writes:
> This doesn't make sense, I think.  font-lock-support-mode is a function,
> and if a user has this set to a non-existent function, the correct
> response is surely to tell her with an error message, rather than
> executing a different function.
>
> The only reason anybody nowadays would set f-l-s-m to 'fast-lock-mode
> would be for debugging.  Let's not make that debugging any more
> difficult than it already is.

Stefan Monnier writes:
> IMNSHO, that variable should not be a defcustom any more and we
> shouldn't encourage users to touch it.  IOW we should mark it obsolete.
>
> We could OTOH add a new command to enter a form of
> `font-lock-debug-mode` which could disable the use of jit-lock (but not
> necessarily in exactly the same way as setting `font-lock-support-mode`
> would, tho it would probably be the most obvious immediate choice in the
> short term).

I guess my suggestion was to change f-l-s-m to a boolean flag in order
to make debugging *easier*.  My own experience, as someone previously
unfamiliar with the font-lock code, was that it took me a while to
discover that setting f-l-s-m to nil is the way to use font-lock
directly, without jit-lock "support".  Neither setting the jit-lock-mode
variable nor calling (jit-lock-mode nil) does this.  The latter will
turn off jit-lock, but doesn't tell font-lock to install its default
change functions.

I was also thinking that treating any non-nil value by using jit-Lock
would provide better backward compatibility.  I later realized that this
is actually a moot point.  The only way that setting f-l-s-m to
'fast-lock-mode will currently work is to also (require 'fast-lock), and
that is going to crash-and-burn once fast-lock-mode.el is gone.

Personally, I like Stefan M's suggestion of creating a new function or
variable and marking f-l-s-m as obsolete, but Eli's point that this
could be disruptive to people who are currently using f-l-s-m for
debugging is also well taken.  Anything that makes it clear how to
disable Jit Lock while still using Font Lock seem like an improvement
to me.

Thanks,
-Jeff

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sun, 09 Aug 2020 15:53:21 -0400
> Cc: Eli Zaretskii <eliz@gnu.org>, stefankangas@gmail.com, emacs-devel@gnu.org
> 
> IMNSHO, that variable should not be a defcustom any more and we
> shouldn't encourage users to touch it.  IOW we should mark it obsolete.

Could you please elaborate on your rationale for this?

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

[Stefan Monnier]

>> IMNSHO, that variable should not be a defcustom any more and we
>> shouldn't encourage users to touch it.  IOW we should mark it obsolete.
> Could you please elaborate on your rationale for this?

AFAIK the only use for it is debugging.
In non-debugging contexts, font-lock-with-jit-lock should "always" give
better behavior than font-lock-without-jit-lock.


        Stefan

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

[Alan Mackenzie]

Hello, Stefan.

On Sun, Aug 09, 2020 at 15:53:21 -0400, Stefan Monnier wrote:
> > I was thinking that a more descriptive name would make it easier for
> > people to figure out what the variable is for.

> IMNSHO, that variable [font-lock-support-mode] should not be a
> defcustom any more and we shouldn't encourage users to touch it.  IOW
> we should mark it obsolete.

In other words, deliberately restrict what users can do with Emacs.
This is surely not a great idea.

At the moment, sensible normal values are nil and jit-lock-mode.  Also
sensible would be, for example, jit-lock-debug-mode, when a user wants
to compare standard jit with her own enhanced version.  It is not
inconceivable that somebody might write something entirely new to
supersede jit-lock.  Why do you want to make these things more difficult
to do?

> We could OTOH add a new command to enter a form of
> `font-lock-debug-mode` which could disable the use of jit-lock (but not
> necessarily in exactly the same way as setting `font-lock-support-mode`
> would, tho it would probably be the most obvious immediate choice in the
> short term).

font-lock-support-mode is _NOT_ obsolete.  It is useful for debugging.
Maybe it needn't be a defcustom any more.  But all the suggestions for
altering it that I've read seem aimed at making Emacs less capable.

Lets leave font-lock-support-mode alone.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Stefan Monnier]

>> We could OTOH add a new command to enter a form of
>> `font-lock-debug-mode` which could disable the use of jit-lock (but not
>> necessarily in exactly the same way as setting `font-lock-support-mode`
>> would, tho it would probably be the most obvious immediate choice in the
>> short term).
>
> font-lock-support-mode is _NOT_ obsolete.  It is useful for debugging.

That's why I propose to replace it with `font-lock-debug-mode`, which
would both help discoverability and make it easier to use as well.


        Stefan

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

[Eli Zaretskii]

> From: Jeff Norden <jnorden@tntech.edu>
> Cc: emacs-devel@gnu.org, stefankangas@gmail.com, monnier@iro.umontreal.ca
> Date: Sun, 09 Aug 2020 16:34:43 -0500
> 
> Anything that makes it clear how to disable Jit Lock while still
> using Font Lock seem like an improvement to me.

Suggestions for how to improve the discoverability of this are
welcome.

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 10 Aug 2020 00:02:01 -0400
> Cc: stefankangas@gmail.com, jnorden@tntech.edu, emacs-devel@gnu.org
> 
> >> IMNSHO, that variable should not be a defcustom any more and we
> >> shouldn't encourage users to touch it.  IOW we should mark it obsolete.
> > Could you please elaborate on your rationale for this?
> 
> AFAIK the only use for it is debugging.
> In non-debugging contexts, font-lock-with-jit-lock should "always" give
> better behavior than font-lock-without-jit-lock.

OK, but why does that mean we should demote it from being a defcustom?
People who need to debug font-lock are also users, and being unable to
change the value through "M-x set-variable" is an annoyance, at least
for me.

Do you see any harm in keeping it as a defcustom?

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

[Jeff Norden]

>> Anything that makes it clear how to disable Jit Lock while still
>> using Font Lock seem like an improvement to me.
>
> Suggestions for how to improve the discoverability of this are
> welcome.

I like Stefan's font-lock-debug suggestion even more as I think about it.
It definitely would have helped me when I was starting out to write
fontification code.  The current situation makes debugging font-lock rather
confusing for someone new.  In addition to the un-helpful name, f-l-s-m only
works if set before font-lock is initialized.  On the other hand,
jit-lock-debug-mode can be invoked at any time.

Historically, I think there was a need to set f-l-s-m to the value that worked
best for the mode one was using.  Now, all it does is enable/disable Jit.  It
seems like the only reason to disable Jit is if fontification isn't working
properly, i.e., for debugging.  This doesn't seem like the sort of thing that
would usually be done via the "Easy Customization" menus.  Furthermore,
"M-x set-variable" doesn't work as expected for f-l-s-m, since it doesn't have
any effect for a buffer that is already running font-lock (this puzzled me at
first).

It also seems to me that the abstraction of a 'minor mode' for font debugging
options doesn't help much, and perhaps just adds to the confusion.  The same
goes for the idea that jit-lock is a mode, rather than just another feature of
font-lock (it isn't defined as a minor mode, in fact).

----
So, here is an idea for consideration:

A new buffer-local variable:  font-lock-debug
The possible values for now (more could be added later) would be:

nil:         normal fontification using Jit
jit-defer:   equivalent to currently setting jit-lock-debug-mode
jit-disable: equivalent to currently having f-l-s-m nil when font-lock starts

This variable could be set via font-lock-defaults like most other font-related
things.

Also add a new command, font-lock-set-debug, for changing font-lock-debug
on the fly. This command would make the required adjustments to the change
functions, jit registration, jit-lock-defer-timer, etc.  This could also be
used for initialization at font-lock startup, and then maybe the remaining
confusing thing-lock things could be obsoleted.

For backward compatibility:

a) When font-lock-mode starts:
if font-lock-support-mode is bound, and
   font-lock-debug is not set in font-lock-defaults, and
   (font-lock-value-in-major-mode f-l-s-m) returns nil,
then set font-lock-debug to 'jit-disable.

b) jit-lock-debug-mode would be a command that uses font-lock-set-debug to
toggle font-lock-debug between nil and jit-defer (or set it to one of those
when given an argument).  If font-lock-debug is jit-disable, this command
would give a "Jit Lock is disabled" message.

---
Here are some ideas for possible future values of font-lock-debug:

keyword-trace: write a line into a *Font Lock Debug* buffer each time a
  keyword matches, including the appropriate match-data values.

jit-trace: write a line into a *Font Lock Debug* buffer each time
  Jit Lock decides to fontify, with the begin and end positions of the chunk.

Thanks,
-Jeff

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

[Alan Mackenzie]

Hello, Stefan.

On Mon, Aug 10, 2020 at 08:07:31 -0400, Stefan Monnier wrote:
> >> We could OTOH add a new command to enter a form of
> >> `font-lock-debug-mode` which could disable the use of jit-lock (but not
> >> necessarily in exactly the same way as setting `font-lock-support-mode`
> >> would, tho it would probably be the most obvious immediate choice in the
> >> short term).

> > font-lock-support-mode is _NOT_ obsolete.  It is useful for debugging.

> That's why I propose to replace it with `font-lock-debug-mode`, which
> would both help discoverability and make it easier to use as well.

What you have done here is to take my words out of context, twist them,
and pretend to be agreeing with me.  Why do you do things like this?

Why can you not have an open honest discussion with me on things we
disagree about?

The necessary context you snipped, from my previous post, is this:

> > At the moment, sensible normal values are nil and jit-lock-mode.
> > Also sensible would be, for example, jit-lock-debug-mode, when a
> > user wants to compare standard jit with her own enhanced version.
> > It is not inconceivable that somebody might write something entirely
> > new to supersede jit-lock.  Why do you want to make these things
> > more difficult to do?

So the question remains: why do you want to make these more advanced
forms of debugging more difficult?  Your "... help both discoverability
and make it easier to use ..." could be summed up as dumming down.

Surely it would be possible to leave font-lock-support-mode with its
current power, while adding on these other things, too?


>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Stefan Monnier]

>> > At the moment, sensible normal values are nil and jit-lock-mode.
>> > Also sensible would be, for example, jit-lock-debug-mode, when a
>> > user wants to compare standard jit with her own enhanced version.
>> > It is not inconceivable that somebody might write something entirely
>> > new to supersede jit-lock.  Why do you want to make these things
>> > more difficult to do?
> So the question remains: why do you want to make these more advanced
> forms of debugging more difficult?

I'm sorry, but you lost me: what "more advanced forms of debugging"?

And in which way would my suggestion make it more difficult: in order to
add a new possible value to `font-lock-support-mode` you'd have to
modify `font-lock.el` or use advice anyway, which you can do just as
well without `font-lock-support-mode`.

> Your "... help both discoverability and make it easier to use ..."
> could be summed up as dumbing down.

Great joke.

> Surely it would be possible to leave font-lock-support-mode with its
> current power, while adding on these other things, too?

What power are you talking about?


        Stefan

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

[Stefan Monnier]

> OK, but why does that mean we should demote it from being a defcustom?

`defcustom` is mostly useful in order to set it globally in your config file.

> People who need to debug font-lock are also users, and being unable to
> change the value through "M-x set-variable" is an annoyance, at least
> for me.

`set-variable` works rather poorly here because it has no immediate
effect on the current buffer (until you re-enable font-lock).

That's why I'm suggesting a `font-lock-debug-mode` instead.

> Do you see any harm in keeping it as a defcustom?

If we add `font-lock-debug-mode` I don't see any benefit in keeping it.
The harm is limited to accumulating cruft.


        Stefan

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > IMNSHO, that variable [font-lock-support-mode] should not be a
  > > defcustom any more and we shouldn't encourage users to touch it.  IOW
  > > we should mark it obsolete.

  > In other words, deliberately restrict what users can do with Emacs.

That puts a harsh face on a statement which has other interpretations.
For instance, one can interpret it as contending that supporting
setting of that variable by users would require a lot of work and the
benefit would not justify all that work.

I don't have an opinion about the question itself, but please don't
demonize the other side of the question.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Jeff Norden]

>   > > IMNSHO, that variable [font-lock-support-mode] should not be a
>   > > defcustom any more and we shouldn't encourage users to touch it.  IOW
>   > > we should mark it obsolete.
>
>   > In other words, deliberately restrict what users can do with Emacs.
>
> That puts a harsh face on a statement which has other interpretations.
> For instance, one can interpret it as contending that supporting
> setting of that variable by users would require a lot of work and the
> benefit would not justify all that work.

I agree.  From my point of view, it seems like the intent of the proposal
was mis-interpreted.  I saw the intent as making it *easier* to do exactly
what was interpreted as being 'deliberately restricted', by providing a
better method which would be simpler, less confusing, and perhaps more
effective.

Another statement that was recently made by Eli in regards to this was:

> OK, but why does that mean we should demote it from being a defcustom?
> People who need to debug font-lock are also users, and being unable to
> change the value through "M-x set-variable" is an annoyance, at least
> for me.

While I think it would actually wind up not being an annoyance, the
statement that 'People who need to debug font-lock are also users' is
something that I wholeheartedly agree with!

In fact, I've personally decided to avoid, as much as possible, the use of
the term 'user' as a pronoun.  People have usernames (and user-passwords)
for logging in.  The term user-interface is helpful, since interface can
refer to many things.  But the person at the keyboard and in front of the
screen is just that - a person.  Of course, there is nothing inherently
wrong with the term 'user'.  But, in many circles (present company excepted)
it seems that 'user' is used to implicitly refer to a subset, often a narrow
subset, of the people who might use software (or anything else).  I think
that using 'person' and 'people' instead of 'user' and 'users' does a better
job of indicating the diversity of folks who might use something.  This
diversity should be given at least some consideration (sometimes a lot),
rather than being shoved under the rug.  Emacs, in particular, does a
better job serving a diverse audience than any other software that I
know of.

Just my 2c, for whatever it might be worth.

Regards,
-Jeff

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: stefankangas@gmail.com,  jnorden@tntech.edu,  emacs-devel@gnu.org
> Date: Mon, 10 Aug 2020 18:25:54 -0400
> 
> That's why I'm suggesting a `font-lock-debug-mode` instead.
> 
> > Do you see any harm in keeping it as a defcustom?
> 
> If we add `font-lock-debug-mode` I don't see any benefit in keeping it.
> The harm is limited to accumulating cruft.

If you are saying that we should make a single change which introduces
font-lock-debug-mode and makes font-lock-support-mode a defvar, then I
agree.  I thought you were advocating to make only the latter change,
and then consider the former at some future time.

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

[Stefan Kangas]

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

> I have no reason to believe that there's a non-negligible number of
> users out there in the wild using fast-lock or lazy-lock, so whether we
> ignore such settings or signal an error for them probably won't make much
> difference either way.  I guess the nicer way is to ignore the setting
> but emit a message, if you really care.

Okay, so maybe it's not worth doing anything about it.

Best regards,
Stefan Kangas

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

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> That's why I'm suggesting a `font-lock-debug-mode` instead.
>>
>> > Do you see any harm in keeping it as a defcustom?
>>
>> If we add `font-lock-debug-mode` I don't see any benefit in keeping it.
>> The harm is limited to accumulating cruft.
>
> If you are saying that we should make a single change which introduces
> font-lock-debug-mode and makes font-lock-support-mode a defvar, then I
> agree.  I thought you were advocating to make only the latter change,
> and then consider the former at some future time.

That sounds good.  Could we perhaps add that as a feature request to the
bug tracker and get rid of fast-lock and lazy-lock to begin with?

Best regards,
Stefan Kangas

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

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Wed, 12 Aug 2020 11:08:21 -0700
> Cc: jnorden@tntech.edu, emacs-devel@gnu.org
> 
> > If you are saying that we should make a single change which introduces
> > font-lock-debug-mode and makes font-lock-support-mode a defvar, then I
> > agree.  I thought you were advocating to make only the latter change,
> > and then consider the former at some future time.
> 
> That sounds good.  Could we perhaps add that as a feature request to the
> bug tracker and get rid of fast-lock and lazy-lock to begin with?

I don't understand: fast-lock and lazy-lock are already in obsolete/,
aren't they?  So what did you mean by "get rid of"?

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

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> I don't understand: fast-lock and lazy-lock are already in obsolete/,
> aren't they?  So what did you mean by "get rid of"?

I mean to delete them.  In other words, to install the patch I
proposed in my original post.

Best regards,
Stefan Kangas

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

[Alan Mackenzie]

Hello, Stefan.

On Mon, Aug 10, 2020 at 18:19:30 -0400, Stefan Monnier wrote:
> >> > At the moment, sensible normal values are nil and jit-lock-mode.
> >> > Also sensible would be, for example, jit-lock-debug-mode, when a
> >> > user wants to compare standard jit with her own enhanced version.
> >> > It is not inconceivable that somebody might write something entirely
> >> > new to supersede jit-lock.  Why do you want to make these things
> >> > more difficult to do?
> > So the question remains: why do you want to make these more advanced
> > forms of debugging more difficult?

> I'm sorry, but you lost me: what "more advanced forms of debugging"?

My mistake, sorry: I was under the false impression that the value of
font-lock-support-mode was a function.  Looking at the code, it might
well have been in the distant past, before jit-lock was introduced in
Emacs 21.1.

[ .... ]

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Wed, 12 Aug 2020 20:53:49 +0200
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, Jeff Norden <jnorden@tntech.edu>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I don't understand: fast-lock and lazy-lock are already in obsolete/,
> > aren't they?  So what did you mean by "get rid of"?
> 
> I mean to delete them.

We don't delete stuff so quickly, so the deletion will have to wait.

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

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Kangas <stefankangas@gmail.com>
>> Date: Wed, 12 Aug 2020 20:53:49 +0200
>> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, Jeff Norden <jnorden@tntech.edu>,
>> 	Emacs developers <emacs-devel@gnu.org>
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> > I don't understand: fast-lock and lazy-lock are already in obsolete/,
>> > aren't they?  So what did you mean by "get rid of"?
>>
>> I mean to delete them.
>
> We don't delete stuff so quickly, so the deletion will have to wait.

Both these libraries were marked obsolete in 22.1.  These are the last
remaining libraries marked obsolete in that version that were not
already deleted in 27.1.  Not sure if I'm missing something, but it
seems to me that this would be a pretty routine deletion?

Best regards,
Stefan Kangas

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

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Wed, 12 Aug 2020 13:25:03 -0700
> Cc: monnier@iro.umontreal.ca, jnorden@tntech.edu, emacs-devel@gnu.org
> 
> > We don't delete stuff so quickly, so the deletion will have to wait.
> 
> Both these libraries were marked obsolete in 22.1.  These are the last
> remaining libraries marked obsolete in that version that were not
> already deleted in 27.1.  Not sure if I'm missing something, but it
> seems to me that this would be a pretty routine deletion?

Sorry for not being more clear.  I meant deleting
font-lock-support-mode: it must be declared obsolete first (which
would require adding the command proposed by Stefan), then, after some
obsolescence time, we could delete font-lock-support-mode, and then we
can delete fast-lock and fuzzy-lock.

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

[Stefan Monnier]

> Sorry for not being more clear.  I meant deleting
> font-lock-support-mode: it must be declared obsolete first (which
> would require adding the command proposed by Stefan),

Agreed.

> then, after some obsolescence time, we could delete
> font-lock-support-mode, and then we can delete fast-lock and
> fuzzy-lock.

Disagreed.  I don't see any reason why we should wait for
`font-lock-support-mode` to disappear before we can get rid of those two
packages that have been officially obsoleted for so many years already.


        Stefan

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

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> Sorry for not being more clear.  I meant deleting
> font-lock-support-mode: it must be declared obsolete first (which
> would require adding the command proposed by Stefan), then, after some
> obsolescence time, we could delete font-lock-support-mode, and then we
> can delete fast-lock and fuzzy-lock.

Ah, okay.  So if I understand correctly we should not pull the trigger
on deleting the libraries fast-lock and fuzzy-lock until we have first
obsoleted and, at a later date, deleted font-lock-support-mode.

Best regards,
Stefan Kangas

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

[Stefan Kangas]

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

> Disagreed.  I don't see any reason why we should wait for
> `font-lock-support-mode` to disappear before we can get rid of those two
> packages that have been officially obsoleted for so many years already.

Just to point out that some other items obsoleted in 23.1 can't be
removed until they are:

    * lisp/subr.el (redisplay-end-trigger-functions)
    * lisp/subr.el (window-redisplay-end-trigger)
    * lisp/subr.el (set-window-redisplay-end-trigger)

These are defined in xdisp.c, window.c and maybe others from a cursory
look.

Best regards,
Stefan Kangas

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

[Jeff Norden]

> Eli Zaretskii writes:
>
>> Sorry for not being more clear.  I meant deleting
>> font-lock-support-mode: it must be declared obsolete first (which
>> would require adding the command proposed by Stefan), then, after some
>> obsolescence time, we could delete font-lock-support-mode, and then we
>> can delete fast-lock and fuzzy-lock.
>
> Ah, okay.  So if I understand correctly we should not pull the trigger
> on deleting the libraries fast-lock and fuzzy-lock until we have first
> obsoleted and, at a later date, deleted font-lock-support-mode.
>
> Best regards,
> Stefan Kangas

I feel like I may be responsible for creating this little mess.  I'm not
sure if I can help clean it up, but I'll try.

Stefan K's original patch was to just delete the old fast-lock and
lazy-lock libraries.  This didn't delete the font-lock-support-mode
variable, but it would have implicitly changed its role.  Instead of
choosing a "support" mode, the only valid values would have been
'jit-lock-mode or 'nil, the latter for debugging.

For all practical purposes, this has actually been the case ever since the
old libraries where obsoleted.  Currently, setting f-l-s-m to anything
other than 'jit-lock or 'nil will only work if you explicitly load one of
the old libraries from the obsolete/ directory.

When I saw the patch, I decided to butt in, and suggested that this would
make the already confusing name "font-lock-support-mode" even more so.
(In hindsight, perhaps f-l-acceleration-mode would have been a better,
albeit even longer, choice.)  I stuck my nose in here because I've recently
been figuring out the details of how font-lock works, and this was one of
the stumbling blocks.

So, I tried to suggest a new variable name, with font-lock-support-mode as
an obsolete-variable-alias.  Stefan M suggested, I think, replacing f-l-s-m
with a minor mode for debugging font-lock.  Anything that makes it easier
for someone new to figure out how to debug their font-lock code when it
fails to work properly would be good.  In any case, it is obviously
important that setting font-lock-support-mode to 'nil should continue to be
supported as a (perhaps obsolete) way of disabling jit-lock without turning
off font-lock.

Thanks, and sorry if I've been the cause of some confusion.

Regards,
-Jeff

BTW: Does anyone know the origin and/or meaning of the use of '-lock' in
font-lock, etc?

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

[Eli Zaretskii]

> From: Jeff Norden <jnorden@tntech.edu>
> Cc: eliz@gnu.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> Date: Thu, 13 Aug 2020 16:30:16 -0500
> 
> I feel like I may be responsible for creating this little mess.

You are not, so you don't need to apologize.

These two packages being in obsolete/ doesn't mean no one is using
them: as long as font-lock-support-mode exists, someone could still
use them, although I agree that the chances of that are very low, to
say the least.  That is why IMO we cannot delete them without first
obsoleting font-lock-support-mode, so that Emacs warns any of its
users, because if someone loads these packages by hand, they don't get
any warning, and might think they can continue using them forever.

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

[Stefan Monnier]

> users, because if someone loads these packages by hand, they don't get
> any warning,

They do get a warning, because we warn every time we load a file from
`lisp/obsolete`.


        Stefan