Hey folks,
To the maintainer of the Java language bundle, I just pulled the latest from svn. I didn't realize if the Java.tmbundle was update, but there are (IMHO) some bugs in the language grammar that I'm running accross that I don't think I've seen before but it's possible I just wasn't looking:
FIRST: When the cursor is immediately outside of a block comment, the scope still shows "comment.documentation.java" or "comment.block.java" when I don't think it should be (imagine the ^ character to be the cursor):
Example: /* some comment here */^ -- or -- /** * My method does this */^ the scope on the outside of the closed comment is being recognized as comment.block.java and comment.documentation.java respectively when really I'm out of the comment blocks.
SECOND: All the code after an abstract method is scoped to meta.definition.method.java, like for Example:
public abstract void doSomething(); // all code in the file below this is scoped to the meta.definition.method.java
if I add a {} at the end of the abstract method signature the scope gets fixed -- but, y'know ... then the compiler complains :-)
Thanks, -steve
On Mar 29, 2006, at 9:02 AM, Steve Lianoglou wrote:
When the cursor is immediately outside of a block comment, the scope still shows "comment.documentation.java" or "comment.block.java" when I don't think it should be (imagine the ^ character to be the cursor):
Example: /* some comment here */^
I had this issue too -- here is Allan's reply (it was off-list):
On Mar 29, 2006, at 1:02 PM, Allan Odgaard wrote:
The attached pictures show an issue with scope. The cursor is outside the comment, but scope is still reported as comment.block.c. When the cursor is moved one more space then the scope reported is correct.
The scope of the caret is that of the character to the left of the caret.
This is a trade-off, but it makes sense most of the time. The alternative would be to use the scope of the character to the right of the caret, but this has disadvantageous as well.
This is an issue for me because I use a macro to insert a newline and '*' bound to the return key. When I move outside the comment and press return that macro is run because TM thinks it is inside the comment.block scope.
The only solution is to modify the language grammar to markup things differently. For example you could assign a name to the last slash (see about language grammars / captures ) and then give a scope selector like: comment.block - meta.end-of-comment.
Regards, -- Daniel
I had this issue too -- here is Allan's reply (it was off-list)
<snip>
This is an issue for me because I use a macro to insert a newline and '*' bound to the return key. When I move outside the comment and press return that macro is run because TM thinks it is inside the comment.block scope.
Hah .. that's exactly how I found that one, too :-)
The only solution is to modify the language grammar to markup things differently. For example you could assign a name to the last slash (see about language grammars / captures ) and then give a scope selector like: comment.block - meta.end-of-comment.
Would it make sense to make that part of the official lang bundle? I'd imagine manay-a-folk would find macro of continuing a block comment w/ a leading "*" when writing up docs.
Thanks for the heads up on that one. -steve
On 29/3/2006, at 18:34, Steve Lianoglou wrote:
The only solution is to modify the language grammar to markup things differently. For example you could assign a name to the last slash (see about language grammars / captures ) and then give a scope selector like: comment.block - meta.end-of-comment.
Would it make sense to make that part of the official lang bundle? I'd imagine manay-a-folk would find macro of continuing a block comment w/ a leading "*" when writing up docs.
It probably wouldn’t be bad with some sort of naming convention for the cases where placing the caret “after” the construct was generally not considered as “on” the construct.
As for the abstract method, currently that and interface methods (wrongly) require the { } after the method prototype.
I have on my to-do that I should fix that part of the Java language grammar, since it does get reported from time to time (apparently people still use Java :p ) -- but so far I haven’t found the time…
If anyone wants to submit a patch :)
On Mar 29, 2006, at 3:28 PM, Allan Odgaard wrote:
As for the abstract method, currently that and interface methods (wrongly) require the { } after the method prototype.
I have on my to-do that I should fix that part of the Java language grammar, since it does get reported from time to time (apparently people still use Java :p ) -- but so far I haven’t found the time…
If anyone wants to submit a patch :)
I'm the original "author" and occasional maintainer of the Java bundle; my presence on the TM list is rather ephemeral at times, however. :-) I've got a fix for the abstract method bug, and a couple of others, I believe. I'll try to commit those soon.
-
Allan Odgaard -
Brian Lalor -
Daniel Harple -
Steve Lianoglou