RE: [External] : Re: Tree-sitter integration in python.el

[Drew Adams <drew.adams@oracle.com>]

> To me, the biggest problem with font-lock-maximum-decoration 
> is that few major modes bothered to implement levels.

That's a problem with the non-few modes that
don't do that.

Some Elisp code has less than stellar doc
strings, and even a lack of doc strings in
some cases.

And much Elisp code uses only rudimentary
defcustom :type specs (e.g. just `sexp'),
instead of specifying just what type of
Elisp values are appropriate, so excluding
inappropriate types.

These are only reasons to encourage _more_
attention to helping users with better doc
etc.  They're by no means reasons not to
bother with font-lock levels, doc, or :type.

(I'm not saying you actually suggested
giving up on font-lock levels, BTW.)

If Emacs's own code hardly bothers with
font-lock levels then it shouldn't be much
of a surprise that 3rd-party code doesn't
bother with them either.  One might even
bet that many who write 3rd-party code are
completely _unaware_ of font-lock levels.

> Given the lack of success of font-lock-maximum-decoration,

See above.  Lack of awareness of it.  Lack
of encouragement to make use of it.

> I don't see this being implemented by many major modes.

Ignorance of Emacs-Lisp coding conventions
is combatted by maintainers reminding about
them, encouraging their respect, and even
requiring their respect for contributions
to Emacs.  Awareness is probably the first
hurdle to putting font-lock levels to use.

One simple analogy - any number of others
could be given:

Just because electoral participation is
limited in some countries (e.g. the USA),
that's not a reason to say that "given the
lack of success" of voluntary electoral
participation we might as well not bother
having elections.

> Also, if the idea does take traction, it will lead
> to a proliferation of user options that is hard
> to use effectively 

Every user option (and face) has a _default_
value, which should be what the designers
think is a good value for most users.

There's nothing wrong with a library
providing options and faces for easy
customization.

Providing a default value has the same effect
as hard-coding the behavior - you get what
you get, OOTB - EXCEPT that you _can_ easily
get other behaviors.  The mere existence of
an option cannot possibly be inferior to
hard-coding the behavior it lets you modify.

That users have many options to easily
change behavior here and there isn't a bad
thing - a limitation.  It's a good thing.

(The only downside to a plethora of options
is that their names show up with completion,
apropos, etc.  And if users start to pay
attention to them, by reading their doc, that
attention takes time.)

> -- if someone doesn't want to fontify built-ins in
> Python, they probably don't want it in other
> languages either, so they need to set a similar
> option for N languages.

And if they don't have those options,
then what?  How do they then get behavior
they want across those N languages?

Nothing prevents a library (or Emacs)
from providing ways to affect multiple
such options together, across your N
languages.

That's not hard to do.  And it lets users
decide for _which N_ of the N+M existing
languages with font-lock levels they really
want to override the default value.

> > Since we are designing a new system, I don’t
> > think we need to resort to the likes of font-lock-ignore.
> 
> It's exactly the opposite: since you are designing
> a new systems, you can create a much nicer
> customization mechanism on the lines of
> font-lock-ignore.  For instance, one could select 
> fontification rules based on the affected node type.
> 
> The “decoration levels” feature can then build up on this, with the
> advantage that it would be consistent across languages and require no
> extra effort from the major mode developer.

See https://lists.gnu.org/archive/html/emacs-devel/2022-04/msg00066.html

I'm not against giving users and library
authors multiple-grain, selective ways to
override/prevent font-locking.  I proposed
this long ago.

I still haven't found the thread where the
current `font-lock-ignore' is introduced, so
it's hard to comment on it.  I asked about
it, but was never pointed to it.

But is it really related to whether it can
be useful to provide more than one font-lock
level?

Both fine-grained and coarse-grained control
over an existing set of font-lock rules and
faces are useful, by both "end" users and
library authors.

Font-lock levels can provide one kind of such
(coarse-grained) control.

Why should the `font-lock-ignore' feature
being discussed (for which I haven't found
any spec or code, the only thread I found for
it starting with Eli's comments [1] on some
previous thread (somewhere?) about "master
5c70ff9") obviate the usefulness of font-lock
levels?  Why does the one preclude use of the
other?
___

[1] https://lists.gnu.org/archive/html/emacs-devel/2022-04/msg00041.html