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




_______________________________________________
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode

Reply via email to