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.