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<monn...@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 > > >
signature.asc
Description: PGP signature
_______________________________________________ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
