I have discovered a couple of oddities in the Python language grammar:
Function names containing digits are not handled the same as functions names that do not contain digits. You can see this by looking at how the following code is highlighted:
def foo(self): pass
def foo2(self): pass I have not spent much time studying TextMate language grammars yet, but it appears that the "begin" regular expression for meta.function.python should be modified to allow digits in the function name.
Type names are highlighted as type names even in contexts where they couldn't possibly be type names. For example, in:
foo.set(x) the member function "set" is highlighted as if it were a type.
A negative look-behind RE could distinguish this specific case. I don't know how many other such cases are lurking in Python.
One could argue that it's bad practice to use type names as method names. Probably so, but it's not always avoidable. In particular, "set" wasn't even a type name until recently, and it's used as a method name in the standard library (e.g., in Tkinter). It's also a very nice verb to use as a method name.
Both of these came up while typing in a single recipe from _Python Cookbook_ (Recipe 11.11 from the 2nd Edition). I hope that's not typical. Syntax coloring needs to be *more* reliable than eyeballing the code.
-Paul paul@mustbeart.com
Paul,
The first bug that you mention was corrected some time ago. What version of TM are you using?
The second one has been corrected in the latest SVN.
- AJ
On Nov 23, 2006, at 7:23 PM, Paul Williamson wrote:
I have discovered a couple of oddities in the Python language grammar:
Function names containing digits are not handled the same as functions names that do not contain digits. You can see this by looking at how the following code is highlighted:
def foo(self): pass
def foo2(self): pass I have not spent much time studying TextMate language grammars yet, but it appears that the "begin" regular expression for meta.function.python should be modified to allow digits in the function name.
Type names are highlighted as type names even in contexts where they couldn't possibly be type names. For example, in:
foo.set(x) the member function "set" is highlighted as if it were a type.
A negative look-behind RE could distinguish this specific case. I don't know how many other such cases are lurking in Python.
One could argue that it's bad practice to use type names as method names. Probably so, but it's not always avoidable. In particular, "set" wasn't even a type name until recently, and it's used as a method name in the standard library (e.g., in Tkinter). It's also a very nice verb to use as a method name.
Both of these came up while typing in a single recipe from _Python Cookbook_ (Recipe 11.11 from the 2nd Edition). I hope that's not typical. Syntax coloring needs to be *more* reliable than eyeballing the code.
-Paul paul@mustbeart.com
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
At 3:27 PM -0800 11/24/06, Alexander Ross wrote:
The first bug that you mention was corrected some time ago. What version of TM are you using?
I was using the current Cutting Edge at the time, build 1324 it was. Presently it's build 1349 and the first problem is indeed fixed. Thanks!
Is there a way to see what version of a bundle is in use, and if there are local modifications in play?
The second one has been corrected in the latest SVN.
Thanks for the quick action!
Is there a way to update a bundle to the latest SVN as a one-time thing, so that it will automatically revert to the mainstream when there's a new Cutting Edge or greater release?
-Paul
On 25. Nov 2006, at 15:10, Paul Williamson wrote:
[...] Is there a way to see what version of a bundle is in use, and if there are local modifications in play?
Sort of, yes.
If you do not have a checkout, i.e. use the included bundles, press ⌃R after this line in TextMate:
cat "$TM_SUPPORT_PATH/version"
This will give the repository revision number at the time of exporting bundles to the build (for r1349 that would be 6194).
If you want to see what has happened with the Python bundle since that revision, you can execute:
svn log -r6194:HEAD http://macromates.com/svn/Bundles/trunk/ Bundles/Python.tmbundle
[...] Is there a way to update a bundle to the latest SVN as a one-time thing, so that it will automatically revert to the mainstream when there's a new Cutting Edge or greater release?
Yes, from the shell do:
# to get proper encoding for svn export LC_CTYPE=en_US.UTF-8
# remove old bundle cd /Applications/TextMate.app/Contents/SharedSupport/Bundles rm -rf Python.tmbundle
# export latest version svn export http://macromates.com/svn/Bundles/trunk/Bundles/ Python.tmbundle
Occasionally the latest bundle will have commands which require updates in other part of the support infrastructure (i.e. the shared support folder, or the plug-in folder), so if you are only interested in the updated language grammar, it might be safer to only update that (which is the Syntaxes folder inside the bundle).
-
Alexander Ross -
Allan Odgaard -
Paul Williamson