#20 better (and more) coloring
this patch fixes some coloring problems. It's made
against 4.70 (I diffed the CVS version against my
debian/sarge python-mode.el: equal)
--- fixed stuff
try:pass colors everything except the :
(same for except and finally)
they still color the colon turquoise if there's at
least one space or newline. If colon-coloring should be
turned off, it's a simple swap-three-lines operation.
it also correctly colors str(id(type(len))); but only
(damn!) because it alternates between typenames and
builtins.
fixes not coloring the last exception in a tuple (and
probably other similar things).
(imo) correctly colors ValueError in
`exceptions.ValueError'.
adds set and frozenset to typenames.
--- tweakable stuff:
selecting alternate face for typenames (int, dict, type)
selecting alternate face for builtins (exceptions, len, id)
(these two defaults to kw-turquoise)
selecting alternate face for numeric literals (but
currently the RE-matching is dodgy)
selecting alternate face for the first variable name in
a for ... in (both expressions and statements) (it
should be extended to more than just the first).
(these two default to a vanilla face, 'py-plain-face)
Logged In: YES
user_id=1153395
sorry, I (something)ed up uploading the patch.
Scene 24, take 2.
a few cases showing what the patch does (and doesn't)
Logged In: YES
user_id=44345
Thanks... I applied the patch locally and will play around with it a bit.
Attached is a slightly tweaked diff. There were a couple rejects because
of other recent changes with the keyword re's. Can you give it a whirl?
Any chance you can fix the FIXMEs? I don't see any coloring for
numeric literals. Should I? I suspect that will be something a lot of
people won't want, so there should be a way to disable it, and that should
probably be the default.
Logged In: YES
user_id=1153395
> There were a couple rejects because of other recent
changes with the keyword re's. Can you give it a whirl?
Sure.
> I don't see any coloring for numeric literals. Should I?
Most likely: no. That is, it won't be colored unless you set
the variable 'py-number-literal-face to something
interesting. I attach $(head .emacs)
> I suspect that will be something a lot of people won't
want, so there should be a way to disable it, and that
should probably be the default.
See above: it is the default.
> Any chance you can fix the FIXMEs?
I'll try. I'll also work or improving the interface to the
'py-whatever-face variables (i.e. put them *above* the "NO
USER DEFINABLE VARIABLES BEYOND THIS POINT")
...Sorry for not replying sooner--I had an exam going on.
Next one is 20th june, after which I'll more or less be away
from my box 'till mid-july :(
But until then, I have about n spare hours a day, of which I
can devote m (where m <= n) to hacking on python-mode.
elisp showing how to utilize the brand new coloring ability
Logged In: YES
user_id=1153395
Hi.
I must admit that I'm a newbie around diffs/patches, so I
hope what I did was all right / The Right Thing:
Applied your patch (giving two rejects), fixing one
(trivially) by hand, fixing a (not-in-patch) spelling error,
and saving that as pristine.el. Also, I made a working copy
of that as python-mode.el
(from original to pristine: pristine.diff)
(difference between my diff and yours: diffs.diff)
noteworthy: differences:
the big chunk: (see below)
leav vs. leave: (the typo)
`(while (and': an extra line of context required in my diff
From there, I added the changes I proposed (most of the
second reject). In its current state, all the `minor' issues
are still as original (as-attribute coloring fixes, seperate
typenames), and I've added coloring to the second variable
in for ... in (plus of course the first). I'm afraid I
wouldn't know how to generalise it to arbitrary numbers of
variables--but one or two variables covers 95%+ of the code
I write.
(from pristine to (my current) python-model.el: current.diff)
Currently, you still have to set non-user-definable
variables to enjoy what I consider the full benefits (i.e.
blue for builtins, green for type names, ... as per the
font-lock-<logical item>-face)
My plan is that if the patches I made apply cleanly, I will
work from
where I am now on resolving the pending issues:
1) adding *correct* numeric literal coloring
2) moving the to-be-user-definable variables above `NO USER
DEFINABLE VARIABLES BEYOND THIS POINT'
And from there, perhaps on extending the use of
variable-name-face to function arguments and maybe(!)
assignment statements. But this is the future future league
stuff; I haven't really thought any of this through.
---
Also, thanks (a lot) for doing s/number/numeric/ in
py-\1-literal-face.
I also added a bit to tests.py. Disregard anything it says about
numeric literal coloring (obviously), just look at all the
pretty
colors :p
---
Jonas Klker
Logged In: YES
user_id=1153395
Hi.
I must admit that I'm a newbie around diffs/patches, so I
hope what I did was all right / The Right Thing:
Applied your patch (giving two rejects), fixing one
(trivially) by hand, fixing a (not-in-patch) spelling error,
and saving that as pristine.el. Also, I made a working copy
of that as python-mode.el
(from original to pristine: pristine.diff)
(difference between my diff and yours: diffs.diff)
noteworthy: differences:
the big chunk: (see below)
leav vs. leave: (the typo)
`(while (and': an extra line of context required in my diff
From there, I added the changes I proposed (most of the
second reject). In its current state, all the `minor' issues
are still as original (as-attribute coloring fixes, seperate
typenames), and I've added coloring to the second variable
in for ... in (plus of course the first). I'm afraid I
wouldn't know how to generalise it to arbitrary numbers of
variables--but one or two variables covers 95%+ of the code
I write.
(from pristine to (my current) python-model.el: current.diff)
Currently, you still have to set non-user-definable
variables to enjoy what I consider the full benefits (i.e.
blue for builtins, green for type names, ... as per the
font-lock-<logical item>-face)
My plan is that if the patches I made apply cleanly, I will
work from where I am now on resolving the pending issues:
1) adding *correct* numeric literal coloring
2) moving the to-be-user-definable variables above `NO USER
DEFINABLE VARIABLES BEYOND THIS POINT'
And from there, perhaps on extending the use of
variable-name-face to function arguments and maybe(!)
assignment statements. But this is the future future league
stuff.
---
Also, thanks (a lot) for doing s/number/numeric/ in
py-\1-literal-face.
I also added a bit to tests.py. Disregard anything it says
about numeric literal coloring (obviously), just look at all
the pretty colors :p
---
Kind regards,
Jonas Klker