[TxMt] Java support in TextMate

[Soryu]

Hey,

I worked a bit on my syntax. I even got around the problem with the  
opening bracket on the next line (thanks to Infininight, may the  
light shine on him).

I've attached my current syntax (It is based on my own version, not  
the 'official' one).
You might not like that I colour every method call.

Brian, I think we should argue (and maybe agree ;-) about out  
different approaches of several scopes. I tried to stick to the  
official Java Language Specification for the scopes, hence my  
colouring of keywords (plus, I did not want to exaggarate it). Then  
we might be able to work out the One and Only™ Java Syntax.

I also am not a fan of all those predefined types with scope  
'support.type.built-ins.java'. Types should not really be styled  
differently, whether they are defined with the Java Class Library or  
by the user. And if someone has an own type that happens to have the  
same name (but different package) as one of those built-ins it is  
styled like one.


>
>>  I guess codesense is the more common term.  I think this would  
>> probably require some kind of plugin.
>>
>
> Probably.  I haven't played with any of the existing tools for code  
> browsing or completion or anything.  I think the code browser with  
> ctags support might be a good start...  I wouldn't even know where  
> to start with this kind of thing, really...

Codesense seems a little more difficult to me. For completion of  
Class/Interface types there should be something like a static list of  
tha Java Class Library. Though different versions of Java will differ  
slighly. Next, a plugin would have to scan all imported types  
recursively. It would need the source directory for that at least,  
plus it would have to scan all jar files, that the project includes  
(ok, this could be done once and cached maybe, if we have the info  
about those libs). All this goes for organizing imports, too.
I plugin with such capability would definitely have to be written in  
Java, which brings up other issues.
Code sensing for variable names would have to honor Java scopes  
(think of bracket levels and variable scopes, not TM scopes).

I have done a recursive includes scanning for php using a php and  
ctags that provides completion for user defined functions
But Java with the jar libs and huge class library is a different beast.

> smart rename/delete etc.

eclipse has the power of the included compiler that scopes the syntax  
100% right, so it always knows, whether something is a variable, type  
or whatever.
Smart rename like refactoring? If you meant that, consider this  
example when trying to refactor the variable 'foo':

public class Test {
	// foo  stores the answer to Life, the Universe and everything <--- foo
	String foo = "bar"; <--- class variable
	
	public static void main(String[] args) {
		String foo = "42"; <--- new variable, shadows the class variable
		System.out.println(foo);
		new Test();
	}
	
	public Test() {
		String foo = "nothing"; <--- another shadow
		System.out.println(foo);
		System.out.println(this.foo); <--- instance of original class variable
	}
}

------- end of code

and the whole thing would be pointless if it was not across the whole  
project (like eclipse does), think of access from a different class  
to foo, or better to a public getter method


OK, don't want to discourage anyone, just my thoughts.


Keep it rolling,
Soryu.


PS: Maybe I'm too much of a perfectionist here (or a pessimist). I'd  
be happy to be surprised that I am wrong on the Codesense/organizing  
imports and refactoring.