digitalmars.D.announce - Updated D TextMate bundle for D2 and TM2
- Jacob Carlborg (26/26) Apr 12 2015 I would like to announced that I have recently updated the D TextMate
- biozic (6/23) Apr 13 2015 Awesome!
- Jacob Carlborg (8/12) Apr 13 2015 No, it's more the order of how rules implemented. I know I had this
- biozic (39/54) Apr 13 2015 For example:
- Jacob Carlborg (7/22) Apr 17 2015 I have fixed this issue now. It's currently in "master", it has not been...
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
Apr 12 2015
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?
Apr 13 2015
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
Apr 13 2015
On Monday, 13 April 2015 at 15:08:47 UTC, Jacob Carlborg wrote:On 2015-04-13 13:39, 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.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.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*)*) (?=\()'; 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.
Apr 13 2015
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
Apr 17 2015