[Python-mode] adding a standard font-lock-number-face

[Barry Warsaw]

On Jun 17, 2011, at 08:34 AM, Andreas Röhler wrote:

>would make a bug report/feature request for that.
>Opinions?

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.

I guess I would compromise by not adding any py-* faces to handle these.  If
there are already existing font-lock-* faces for these types of things, adding
some regexps to recognize them in Python code would be okay, as long as
performance doesn't suffer.

Just my opinion though.
-Barry

>
>Am 17.06.2011 05:54, schrieb Fabian Ezequiel Gallina:
>> 2011/6/17 Stefan Monnier<monnier at 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
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-mode/attachments/20110617/c2c43b3f/attachment.pgp>