Sublime Forum

[Syntax] How to add a rule to an included scope?

#1

I’m aware of with_prototype that adds the rules to the scopes prototype, but I was wondering if there was a way to include a rule as part of the included scopes main context?

includeOtherSyntax:
  - match: '{'
    set: Packages/MySyntax/MyIncludedSyntax.sublime-syntax
    with: # <- some special keyword to merge this with main
      - match: '}'
        pop: true

I don’t want to add my pop rule to with_prototype because } is a valid character in my included syntax so i don’t want to mess with that. Instead I only want my pop rule to be considered if there are no other contexts on the stack.

This is the hack I’ve come up with for now, but I lose the source.myincludedsyntax scope.

MyIncludedSyntax.sublime-syntax:

# define a custom scope that is used only for including
included:
  # The prototype is not applied here, so we need to duplicate it
  - include: comments
  - include: main
  - match: '(?=})'
    pop: true

MySyntax.sublime-syntax:

popClosingBrace:
  - match: '}'
    pop: true

optionAfterAssignment_POP:
  - match: '{'
    set:
      - popClosingBrace
      - Packages/MySyntax/MyIncludedSyntax.sublime-syntax#included
2 Likes
#2

+1. I have a similar problem and something along the lines of your proposal would be very useful. I would like to extend the distributed TCL syntax to make it specific for particular tools that provide their own custom commands. Right now I do that by copying the whole TCL syntax file distributed and extending the “commands” and “command-name” contexts for my purposes, but that requires me to manually update my syntax whenever the distributed TCL syntax gets an improvement or fix

In my case, I would want to be able to extend contexts of another syntax, but in a way that those modifications apply even when that context is reached within that other syntax. For example, I would propose something like this:

main:
- include: Packages/TCL/Tcl.sublime-syntax
  with_contexts:
    - name: commands
      include: 
        # include can be expanded here with many 'match' and other 'include' rules 
        # to be added (in this case) to the Tcl.sublime-syntax#commands context
        - include: my_command_extensions_context
        - match: '}'  
          pop: true
    - name: command-name
      include: my_command_name_extension_context
      # or it can be explicitly another named context to be included (in this case) in
      # the Tcl.sublime-syntax#command-name context

I think this can solve your case too if the syntax file referenced is qualified by the specific context you want to include, push or set, ant then that is the only context you modify in the “with_contexts” list.

1 Like
#3

Since you don’t want your pattern to match when inside a stacked context, you cam just have it in the same context as the include (not push) for the external syntax.

0 Likes
#4

That’s exactly what I want, but I don’t quite understand what you are saying :slight_smile:

I’m going to try and guess:

optionAfterAssignment_POP:
  - match: '{'
    set:
      - include: popClosingBrace
      - include: Packages/MySyntax/MyIncludedSyntax.sublime-syntax

If I do it this way, it includes the main context, but it doesn’t apply the prototype from the included context. i.e., I lose MyIncludedSyntax.sublime-syntax#comments. It also doesn’t add a source.myincludedsyntax scope.

0 Likes
#5

The prototype thing is a known issue. The workaround is to add another include that explicitly references the prototype context.

For the context, you’ll need to add a meta_content_scope to add the scope back in.

You’ll end up with this:

contexts:
  optionAfterAssignment_POP:
    - match: '{'
      set:
        - meta_content_scope: source.myincludedsyntax
        - include: popClosingBrace
        - include: Packages/MySyntax/MyIncludedSyntax.sublime-syntax#prototype
        - include: Packages/MySyntax/MyIncludedSyntax.sublime-syntax
0 Likes