I would like to announced that I have recently updated the D TextMate bundle to support D2 and TextMate 2. On a high level what's changed:

* The language grammar is up to date with D2 (I probably forgot something)
* Commands for building/running with RDMD and Dub
* Cleanup obsolete snippets and commands
* Some minor adjustments to make it compatible with TextMate 2
* Takes advantage of the new gutter marks in TextMate 2 for compiler messages
* Completely new internals for the build and run commands
* Update snippets to follow Phobos style guides

The build/run commands will create links in the output window which points back to the editor for compile errors, warnings and deprecation messages. When running an application it will also do the same thing for any exceptions that are thrown. It will also add these messages as marks in the gutter view.

For information about the build/run commands and how to configure the compiler (if needed) see the built-in help command for the bundle (Bundles -> D -> Help), also present here [1].

I would say that this bundle has a pretty good foundation now but it doesn't contain any advanced/fancy features, like autocompletion with DCD.

The bundle is available through TextMate's built-in bundle/package manger (TextMate -> Preferences -> Bundles). For those who already have the bundle the update should be automatic.

[1] https://github.com/textmate/d.tmbundle/blob/master/Support/help.md

-- 
/Jacob Carlborg

On Monday, 13 April 2015 at 06:56:16 UTC, Jacob Carlborg wrote:
> I would like to announced that I have recently updated the D TextMate bundle to support D2 and TextMate 2. On a high level what's changed:
>
> * The language grammar is up to date with D2 (I probably forgot something)
> * Commands for building/running with RDMD and Dub
> * Cleanup obsolete snippets and commands
> * Some minor adjustments to make it compatible with TextMate 2
> * Takes advantage of the new gutter marks in TextMate 2 for compiler messages
> * Completely new internals for the build and run commands
> * Update snippets to follow Phobos style guides
> 
> [...]
> I would say that this bundle has a pretty good foundation now but it doesn't contain any advanced/fancy features, like autocompletion with DCD.

Awesome!

The only quirk I can see so far is that `xxx yyy(` is always parsed so that yyy is considered to be the symbol of a function, is highlighted as such, and appears in the symbol tree. Is it a limitation of Textmate?

On 2015-04-13 13:39, biozic wrote:

> Awesome!
>
> The only quirk I can see so far is that `xxx yyy(` is always parsed so
> that yyy is considered to be the symbol of a function, is highlighted as
> such, and appears in the symbol tree. Is it a limitation of Textmate?

No, it's more the order of how rules implemented. I know I had this problem with "static assert". The solution I used was to added the rule for "static assert" before the rule for a method. What particular code is there a problem with?

Perhaps I should just move the rule for a method to be the last rule.

-- 
/Jacob Carlborg

On Monday, 13 April 2015 at 15:08:47 UTC, Jacob Carlborg wrote:
> On 2015-04-13 13:39, biozic wrote:
>
>> Awesome!
>>
>> The only quirk I can see so far is that `xxx yyy(` is always parsed so
>> that yyy is considered to be the symbol of a function, is highlighted as
>> such, and appears in the symbol tree. Is it a limitation of Textmate?
>
> No, it's more the order of how rules implemented. I know I had this problem with "static assert". The solution I used was to added the rule for "static assert" before the rule for a method. What particular code is there a problem with?

For example:
---
version (all)
{
    struct foo { int i; }

    auto bar()
    {
        static if (true) {}
        static assert(true);
        return foo(1);
    }
}
---

In the body of the bar function, `if`, `assert` and `foo` are parsed as a method definition and appear in the symbol tree.

> Perhaps I should just move the rule for a method to be the last rule.

Not enough I think. Rather, the method rule shouldn't match if the method name is a keyword or if it starts with `return`. This seems to work around these problems:
{	name = 'meta.definition.method.d';
			begin = '(?x)^\s*(?!\breturn\b)
					((?:\b(?:public|private|protected|package|static|final|synchronized|abstract|export|override|auto|nothrow|immutable|const|inout|ref|shared)\b\s*)*) # modifier
					(?:([^\s]+))\s+ # return type
					((?!\bif\b)(?!\bassert\b)\w+)\s* # identifier
					(?=\()';
			end = '(?={|;)';
			beginCaptures = {
				1 = { name = 'storage.modifier.d'; };
				2 = { patterns = ( { include = '$base'; } ); };
				3 = { name = 'entity.name.function.d'; };
			};
			patterns = (
				{	include = '$base'; },
				{	include = '#block'; },
			);
		},

Also, you forgot the `package` protection keyword (plus optional identifier list) in several places.

On 2015-04-13 22:40, biozic wrote:

> For example:
> ---
> version (all)
> {
>      struct foo { int i; }
>
>      auto bar()
>      {
>          static if (true) {}
>          static assert(true);
>          return foo(1);
>      }
> }
> ---
>
> In the body of the bar function, `if`, `assert` and `foo` are parsed as
> a method definition and appear in the symbol tree.

I have fixed this issue now. It's currently in "master", it has not been pushed to users yet.

The issue was a silly mistake by me, I had forgot to add optional whitespace in the beginning of the rule matching static if/assert.

-- 
/Jacob Carlborg