On 21 Oct 2018, at 08:54, Allan Odgaard <mailinglist@textmate.org> wrote:

On 17 Oct 2018, at 17:36, Jacob Carlborg wrote:

This is exactly according to the specified grammar [3] and it seems to be working as expected. Not sure if the optional group workaround causes some performance implications.

This technique seems like it could be a viable alternative to supporting variables in the TextMate grammar as has been discussed before.

Just to be clear, you are talking about variables from the parsed language and highlighting them later in the scope, right?

So something like: let foo = 42 in … something_with foo … and here the latter instance of foo would be marked as a variable?

No, I’m talking about having variables in the grammar with reusable regular expression snippets. Something like:

{
  patterns = (
    {
      name = 'meta.definition.class.d';
      match = 'class $identifier’; // the “identifier” variable referenced/interpolated
    }
  );
  repository = {
    variables = {
      identifier = '(\w+)';
    };
  };
}

In the above example “identifier” would be a variable that can be interpolated in other rules.

The above example would be one approach. Another approach to support variables is what I showed in my original post but using already existing features of regular expression.

{
  patterns = (
    {
      name = 'meta.definition.class.d';
      match = ‘\g<class_declaration>’; // this is standard regular expression syntax that works today in TextMate we just need somewhere to define “class_declaration"
    },
    {
      name = ‘meta.definition.struct.d’;
      match = ’struct\s+\g<identifier>’; // reusing the “identifier” sub expression in another pattern
    }
  );
  repository = {
    defines = '(?x) // here sub expressions can be defined which can later be used in “patterns"
      (?<class_declaration>class\s+\g<identifier>)
      (?<identifier>\w+)
    ‘;
  };
}

This is all about how one can write/implement a TextMate grammar. This approach would allow to write a TextMate grammar that closely follows a “real” grammar for a programming language, like a BNF grammar. I hope this makes it a bit more clear.

--
/Jacob Carlborg