> Looking at the diff, the b was previously a <, so the intent was to
> convert \< to \b (because of a change in the regexp library), but
> accidentally all <’s where converted to b’s.
>
> I have now reverted this part of r976, better late than never :)
Excellent! My first bug report and fix! Most exciting. Please forgive my enthusiasm; I only came to programming in a serious way about a year ago. I was 'inspired' to do so by a custom program my company rolled out that was so astonishingly awful that I felt that I had to demonstrate that better could be done. So, a year later, with 20+ newly purchased yet well worn O'Reilly titles on my shelf, it's nice to be able to start contributing back to projects I like.
In addition, I have found another small problem with the Python bundle - it has to do with the way it scopes 'meta.item-access.python' sections.
In particular, it gets confused by the end ], and does not recognize it as 'punctuation.definition.arguments.end.python', although it recognizes the lead [ correctly as 'punctuation.definition.arguments.start.python'. For instance, put the following in TextMate as Python, and note the scopes/coloring of the []'s.
pairing_name = findNextWord(packet[row])[0]
The regexes responsible are below, along with my explanation of the problem and proposed fix:
{ name = 'meta.item-access.python';
begin = '(?=[A-Za-z_][A-Za-z0-9_]*(?:\.[a-zA-Z_][a-zA-Z_0-9]*)*\s*\[)';
end = '(\])';
patterns = (
{ begin = '(?=[A-Za-z_][A-Za-z0-9_]*(?:\.[A-Za-z_][A-Za-z0-9_]*)*\s*\[)';
end = '(?=\s*\[)';
patterns = ( { include = '#dotted_name'; } );
},
{ begin = '(\[)';
end = '(?=\])';
beginCaptures = { 1 = { name = 'punctuation.definition.arguments.begin.python'; }; };
endCaptures = { 1 = { name = 'punctuation.definition.arguments.end.python'; }; };
patterns = ( { include = '$base'; } );
contentName = 'meta.item-access.arguments.python';
},
The problem is that the 'meta.item-access.python' begin regex tags a LOCATION, specifically the location of the beginning of the first legit Python dotted name followed by a [, thus correctly allowing the [ itself to be matched within by 'punctuation.definition.arguments.begin.python'. However, the 'meta.item-access.python' end regex tags not the LOCATION of the end ], but the end ] itself, thus preventing 'punctuation.definition.arguments.end.python' from selecting the end ] as it should. In addition, the regex for 'punctuation.definition.arguments.end.python', instead of selecting the end ], selects the LOCATION followed by an end ], which gives it no characters in its scope!
My proposed fix swaps the two; both the start and end 'meta.item-access.python' regexes select for LOCATION, and both 'punctuation.definition.arguments.begin.python' and 'punctuation.definition.arguments.end.python' select for the actual CHARACTERS [ and ]. The code is below, and I have tested that it properly scopes the Python constructs now.
{ name = 'meta.item-access.python';
begin = '(?=[A-Za-z_][A-Za-z0-9_]*(?:\.[a-zA-Z_][a-zA-Z_0-9]*)*\s*\[)';
end = '(?<=\])';
patterns = (
{ begin = '(?=[A-Za-z_][A-Za-z0-9_]*(?:\.[A-Za-z_][A-Za-z0-9_]*)*\s*\[)';
end = '(?=\s*\[)';
patterns = ( { include = '#dotted_name'; } );
},
{ begin = '(\[)';
end = '(\])';
beginCaptures = { 1 = { name = 'punctuation.definition.arguments.begin.python'; }; };
endCaptures = { 1 = { name = 'punctuation.definition.arguments.end.python'; }; };
patterns = ( { include = '$base'; } );
contentName = 'meta.item-access.arguments.python';
},
);
},
Hope this is helpful - I am (slowly!) looking through the rest of the Python language definition to see if there are any other glitches I can spot. Cheers,
Nick