adding a standard font-lock-number-face

adding a standard font-lock-number-face

[Fabian Ezequiel Gallina]

Hi devs,

In the python.el bugtracker[0] an interesting discussion started about
highlighting numbers in python.el.

I'm kinda against of adding a custom python.el face for it and
contribute to the non-standard faces hell we already face from other
packages which make Emacs hard to theme.

So the first idea the user mentioned when I rejected such approach was
using font-lock-constant-face which sounds good, but I don't think
I've seen another package to do such thing, and I'm sure most Emacs
users are accustomed to see numbers in a different decoration than
constants.

So long story short: isn't a good idea to add a standard
font-lock-number-face in order to have fine grained control on
font-lock and give the users the chance to customize numbers
decoration out of the box?


[0] https://github.com/fgallina/python.el/issues/42

Thanks,
-- 
Fabián E. Gallina

Re: adding a standard font-lock-number-face

[Stefan Monnier]

> So long story short: isn't a good idea to add a standard
> font-lock-number-face in order to have fine grained control on
> font-lock and give the users the chance to customize numbers
> decoration out of the box?

I don't think highlighting tokens that are only lexically relevant but
not syntactically relevant is a good idea.
E.g. it's good to highlight keywords because they determine structure.
It's good to highlight strings and comments because keywords within them
*don't* determine structure.
It's good to highlight identifier definitions because these are
semantically important and they tend to be a bit like section titles, so
syntactically meaningful.

But it's not useful to highlight all identifiers, or all numbers, or all
separators, or all infix operators, ... because that doesn't help the
user navigate his code.


        Stefan

Re: adding a standard font-lock-number-face

[Fabian Ezequiel Gallina]

2011/6/17 Stefan Monnier <monnier@iro.umontreal.ca>:
>> So long story short: isn't a good idea to add a standard
>> font-lock-number-face in order to have fine grained control on
>> font-lock and give the users the chance to customize numbers
>> decoration out of the box?
>
> I don't think highlighting tokens that are only lexically relevant but
> not syntactically relevant is a good idea.
> E.g. it's good to highlight keywords because they determine structure.
> It's good to highlight strings and comments because keywords within them
> *don't* determine structure.
> It's good to highlight identifier definitions because these are
> semantically important and they tend to be a bit like section titles, so
> syntactically meaningful.
>
> But it's not useful to highlight all identifiers, or all numbers, or all
> separators, or all infix operators, ... because that doesn't help the
> user navigate his code.
>

Thanks for the clarification Stefan, I was pretty sure there was a
good reason why it wasn't there already.

An argument I can think of for inclusion is that it seems highlighting
those kind of stuff (event operators) is really common on other
editors, so it is acceptable that people coming from other places
would expect this kind of stuff highlighted out-of-the-box. I know the
"people coming from other editors" argument is kinda weak, but I don't
see why not giving them the chance to enable that easily in a vanilla
Emacs.

Please note that I'm no expert at font-locking but I think it might be
good (and possible) to let modes to specify a higher or special level
of font-locking so this kind of things can be highlighted. Let the
default be the standard Emacs way, but giving the users the chance to
enable that special level easily. This way standard font-lock
performance shouldn't be hit.

What do you think?


Regards,
-- 
Fabián E. Gallina

Re: adding a standard font-lock-number-face

[Andreas Röhler]

Am 17.06.2011 05:54, schrieb Fabian Ezequiel Gallina:
> 2011/6/17 Stefan Monnier<monnier@iro.umontreal.ca>:
>>> So long story short: isn't a good idea to add a standard
>>> font-lock-number-face in order to have fine grained control on
>>> font-lock and give the users the chance to customize numbers
>>> decoration out of the box?
>>
>> I don't think highlighting tokens that are only lexically relevant but
>> not syntactically relevant is a good idea.
>> E.g. it's good to highlight keywords because they determine structure.
>> It's good to highlight strings and comments because keywords within them
>> *don't* determine structure.
>> It's good to highlight identifier definitions because these are
>> semantically important and they tend to be a bit like section titles, so
>> syntactically meaningful.
>>
>> But it's not useful to highlight all identifiers, or all numbers, or all
>> separators, or all infix operators, ... because that doesn't help the
>> user navigate his code.
>>
>
> Thanks for the clarification Stefan, I was pretty sure there was a
> good reason why it wasn't there already.
>
> An argument I can think of for inclusion is that it seems highlighting
> those kind of stuff (event operators) is really common on other
> editors, so it is acceptable that people coming from other places
> would expect this kind of stuff highlighted out-of-the-box. I know the
> "people coming from other editors" argument is kinda weak, but I don't
> see why not giving them the chance to enable that easily in a vanilla
> Emacs.
>
> Please note that I'm no expert at font-locking but I think it might be
> good (and possible) to let modes to specify a higher or special level
> of font-locking so this kind of things can be highlighted. Let the
> default be the standard Emacs way, but giving the users the chance to
> enable that special level easily. This way standard font-lock
> performance shouldn't be hit.
>
> What do you think?
>
>
> Regards,

Hi Fabian,

don't know if my opinion here values a cent at all, :) but let me tell 
that IMO you are right. As long as the default set not differs ie 
inherits from default face, the user normally will not notice that 
customizable.

OTOH user looking for will find it.

Cheers,

Andreas

Re: adding a standard font-lock-number-face

[Stephen J. Turnbull]

Fabian Ezequiel Gallina writes:

 > Please note that I'm no expert at font-locking but I think it might be
 > good (and possible) to let modes to specify a higher or special level
 > of font-locking so this kind of things can be highlighted.

C-h v font-lock-maximum-decoration RET

Of course not all modes use this variable.

Re: adding a standard font-lock-number-face

[Stefan Monnier]

>> Please note that I'm no expert at font-locking but I think it might be
>> good (and possible) to let modes to specify a higher or special level
>> of font-locking so this kind of things can be highlighted.
> C-h v font-lock-maximum-decoration RET
> Of course not all modes use this variable.

I'd be happy to throw it away, indeed, because it gives the wrong
impression that there's a strong ordering of "levels" of decoration,
whereas that is not true.

You may like some elements to be decorated with lots of details, but
want to leave some other element mostly plain and vice-versa.

And furthermore, it tends to conflate "work needed to find what to
highlight" with "amount of different faces one screen at the same time",
even though the two aren't necessarily connected either.

Finally, this variable has had t (aka "use the max") as its default
value forever, so it can't be used to tell Emacs to do "even more than
the default".


        Stefan

Re: adding a standard font-lock-number-face

[Stefan Monnier]

> An argument I can think of for inclusion is that it seems highlighting
> those kind of stuff (event operators) is really common on other
> editors, so it is acceptable that people coming from other places
> would expect this kind of stuff highlighted out-of-the-box.  I know the

I haven't seen many complaints about it either in emacs-devel or
gnu-emacs-help, so I don't think it makes much difference.  People do
not expect one editor to behave exactly like another.


        Stefan

Re: adding a standard font-lock-number-face

[Lennart Borgman]

On Fri, Jun 17, 2011 at 15:38, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> An argument I can think of for inclusion is that it seems highlighting
>> those kind of stuff (event operators) is really common on other
>> editors, so it is acceptable that people coming from other places
>> would expect this kind of stuff highlighted out-of-the-box.  I know the
>
> I haven't seen many complaints about it either in emacs-devel or
> gnu-emacs-help, so I don't think it makes much difference.  People do
> not expect one editor to behave exactly like another.

I have a module, ocr-user.el in nXhtml which highlight OCR numbers
(with digits in groups of 3) so I can more safely pay my bills through
the internet. Maybe that can be enhanced and used?

Re: adding a standard font-lock-number-face

[Fabian Ezequiel Gallina]

2011/6/17 Stefan Monnier <monnier@iro.umontreal.ca>:
>> An argument I can think of for inclusion is that it seems highlighting
>> those kind of stuff (event operators) is really common on other
>> editors, so it is acceptable that people coming from other places
>> would expect this kind of stuff highlighted out-of-the-box.  I know the
>
> I haven't seen many complaints about it either in emacs-devel or
> gnu-emacs-help, so I don't think it makes much difference.  People do
> not expect one editor to behave exactly like another.
>

Think of it of as a feature request, not a problem. I think it might
be good to have some way to define those kind of *extra* fancy stuff
and standardize them (even if not enabled by default). In my opinion,
that will likely help also to improve things avoiding the creation of
new non standard faces in external packages.

Even when I'm writing that, I feel we could also define a set standard
faces for package developers to use in their special modes. I guess
this can be the start of more complete font-locking framework that
could lead to help Emacs to be simple to theme, avoiding the need to
define a hundred faces to make themes work OK with your custom
packages.


Regards,
-- 
Fabián E. Gallina

Re: adding a standard font-lock-number-face

[Stefan Monnier]

> Think of it of as a feature request, not a problem.

That's the way I think of it, yes.

> and standardize them (even if not enabled by default). In my opinion,
> that will likely help also to improve things avoiding the creation of
> new non standard faces in external packages.

Show me the packages which have a "number-face" and could hence benefit
from sharing a standardized face for it.


        Stefan

Re: adding a standard font-lock-number-face

[Donald Ephraim Curtis]

Deadlock :: http://mail.python.org/pipermail/python-mode/2011-June/001161.html

So python-mode/python.el *would*, but since Emacs doesn't have a "number-face" built in, they dare not.  And Emacs won't because no packages do – although `jdee` does define a `jde-java-font-lock-number-face`.




On Jun 17, 2011, at 11:25, Stefan Monnier wrote:

>> that will likely help also to improve things avoiding the creation of
>> new non standard faces in external packages.
> 
> Show me the packages which have a "number-face" and could hence benefit
> from sharing a standardized face for it.

Re: adding a standard font-lock-number-face

[Glenn Morris]

Donald Ephraim Curtis wrote:

> Deadlock ::
> http://mail.python.org/pipermail/python-mode/2011-June/001161.html

Quote from that link:

    Personally, I think it's overkill. I agree that making the default
    indistinguishable would lessen the fruit salad look, but I wonder if
    it's really all that useful.

> So python-mode/python.el *would*, but since Emacs doesn't have a
> "number-face" built in, they dare not.

That's not at all how I would summarize the mail you link to.

Re: adding a standard font-lock-number-face

[Donald Ephraim Curtis]

Hi,

I was originally the person that brought this to Fabian's attention, and so it was my "complaint".  But he's more-correct in that it's not a "complaint" as much as something I like.  

There are numerous posts elsewhere where people have fixed this issue by adding some elisp to their personal configs; i will not fill this thread with links to prove the point.  I currently do this in my configuration file.  Performance doesn't seem to be an issue.  As well, there are plenty of other editors (whose authors are developers themselves) that also must find this useful; since they include this highlighting.  This doesn't mean Emacs should go jump off a bridge (because their friends are doing it).

I don't understand why syntax highlighting has to *only* signify structure.  More important is to help me (the user/developer) navigating the code.  I personally find highlighting numbers does help me navigate code; especially in debugging.\b  Highlighting should be useful over being "technically consistent".

Regardless of opinions, limiting the available faces limits theme designers and ultimately limits the user.  The default can always be to inherit the default-face.  At least then there is a face for this type of thing that modes and themes can use.  

This is just an opportunity for Emacs to include some better (i.e., expected, standard, common, etc.) defaults.  Maybe that's not the point, but everytime it takes me an hour or more – because i'm a newb – to do something I think should be really simple, I'm a bit annoyed.  So then I think, maybe I could fix this for future generations.  And here we are.


argument against myself: it's easy to add into your personal config so no big deal.

--
Donald Ephraim Curtis
dcurtis@milkbox.net




On Jun 17, 2011, at 10:14, Fabian Ezequiel Gallina wrote:

> 2011/6/17 Stefan Monnier <monnier@iro.umontreal.ca>:
>>> An argument I can think of for inclusion is that it seems highlighting
>>> those kind of stuff (event operators) is really common on other
>>> editors, so it is acceptable that people coming from other places
>>> would expect this kind of stuff highlighted out-of-the-box.  I know the
>> 
>> I haven't seen many complaints about it either in emacs-devel or
>> gnu-emacs-help, so I don't think it makes much difference.  People do
>> not expect one editor to behave exactly like another.
>> 
> 
> Think of it of as a feature request, not a problem. I think it might
> be good to have some way to define those kind of *extra* fancy stuff
> and standardize them (even if not enabled by default). In my opinion,
> that will likely help also to improve things avoiding the creation of
> new non standard faces in external packages.
> 
> Even when I'm writing that, I feel we could also define a set standard
> faces for package developers to use in their special modes. I guess
> this can be the start of more complete font-locking framework that
> could lead to help Emacs to be simple to theme, avoiding the need to
> define a hundred faces to make themes work OK with your custom
> packages.
> 
> 
> Regards,
> -- 
> Fabián E. Gallina
>