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

[Andreas Röhler]

Am 17.06.2011 14:17, schrieb 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.

Agreed, will not use that. However, as the OP pointed at, users 
switching from other editors asked for.

IMHO a similar thing as with intellisense, which isn't that useful as it 
looks nice. In some time we should have that too for the reasons above.


  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

OK, that should be a path,

Andreas

>
>>
>> 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
>>
>>
>>