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

Andreas Röhler andreas.roehler at online.de
Fri Jun 17 15:46:43 CEST 2011

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,


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

More information about the Python-mode mailing list