[TxMt] Re: Bundle snippets scope selector -- excluding scope?

[Allan Odgaard]

On 5 Dec 2013, at 4:45, Harald Lapp wrote:

> […] i wonder if there is no way to tell a "sub-scope" to not inherit
> things like tab-triggers?

Not per se, but what you can do is create a new macro, the process is a 
little cumbersome:

     Start recording: Edit → Macros → Toggle Macro Recording 
(⌥⌘M)
     Press tab in a document (this should not expand a tab trigger)
     Stop recording: Edit → Macros → Toggle Macro Recording 
(⌥⌘M)
     Save macro: Edit → Macros → Save Macro… (⌃⌘M)

This should give you a macro with the following content:

     ( { command = 'insertTab:'; } )

Now give the macro the tab key as key equivalent and a scope of 
comment.block.documentation.phpdoc.php.

This will effectively make tab always be a “real” tab in PHP 
documentation comments.

This is not ideal because it disables all snippets for the above scope, 
so if you have PHPDoc snippets or other general snippets (inserting 
current date, author name, etc.) then these will also be disabled.

> i don't want to annoy anybody with these things, but shouldn't there
> be a possibility to "reset" all tab-triggers in a sub-scope?

So far we’ve considered it the responsibility of the bundle item, to 
limit itself to the proper scope.

I see how this can get tedious, because effectively all code snippets 
should have “- (string | comment)”, although for strings, some 
languages can have embedded code in strings, so we need a more complex 
scope selector there, and likewise for HTML (ensuring that they only 
fire when in a “proper” HTML scope, not embedded code or commments).

I don’t see an obvious way to specify a “reset” because I don’t 
think you want to reset everything, e.g. we have an isoD⇥ snippet that 
I would still want in documentation comments.

So I think what is needed is to declare that certain scopes are 
“context switches” (source, text, comment, string) and then allow a 
scope selector to “anchor” the match against the “current” 
context.

Though having to specify an anchor marker in the scope selector does not 
fix the issue gracefully, as we’d need to add it to pretty much all 
scope selectors, so perhaps this should actually be implicit (if the 
scope selector starts with one of the scopes that is considered a 
“context switch”), but with a way to not anchor the snippet.