Packages: [ShellScript] Change applicable scope of snippets

[Phidica]

The ShellScript snippets for case, if, elif, for, until, and while are all applied to the scope of source.shell. However, they are only valid for source.shell.bash and similar shells. They aren't valid in, for instance, the fish shell, which uses the scope source.shell.fish. These snippets being offered when writing in fish gets in the way of selecting the actual fish snippets to correctly construct these command blocks. I think the snippets need to be scoped to source.shell.bash instead.

[rwols]

I'm all for this, but changing the scope of the snippets breaks compatibility with users still using the (deprecated?) Shell-Unix-Generic syntax. For instance, some users had a few problems with the ApplySyntax plugin, although I see now that that has been fixed. I think we can at least go ahead and make the pull request to see what the maintainer thinks of it.

[nhooyr]

Fish should have its own scope source.fish instead of being a subtype of shell. Its unfortunate but putting it under shell only helps for organizational purposes, its syntax and usage is very different from other shells.

[Phidica]

Hmm. Originally I did have the scope as source.fish, but changed it to bring it in line with that used for other shells. The problem is really that source.shell existed for a time as a specific syntax rather than as a prefix for further specification of shells. But if source.shell is deprecated now as a specific syntax, then I would prefer to co-operate with making it a useful organisational prefix for shell syntaxes such as fish, bash, and so on

[rwols]

I wrote this build system in the hopes that other shell syntaxes would make use of it. e.g. just hit CTRL+B when viewing a sh/bash/zsh/fish file and it'll run the contents. It'll only get picked up when the base scope starts with source.shell.

There's also the #!/usr/bin/env ... snippet which will trigger when the base scope is source.shell. Some snippets independent of control flow may also benefit from a common source.shell scope, e.g. having a snippet like tar --directory ${1:directory} --extract --file ${2:file} makes sense in any shell script.

[nhooyr]

How about we put all the other shells under source.shell.posix for shells that conform to posix syntax and then just have fish at source.shell.fish?

That'd be a pretty clean way to solve this.

[FichteFoll]

Good idea on grouping of similar shells. I'm not too much into the differences of shells and their history, but what about source.shell.bourne.bash and source.shell.fish?

[Phidica]

We should probably come to some preliminary decision, and I'll take it to a PR

Looking back through this, I'm not entirely sure I see a need for adding another layer to the scope hierarchy. We could simply stick with
source.shell.bash
source.shell.fish
source.shell.zsh (http://github.com/molovo/sublime-zsh is 2 years stale and using source.shell)
source.shell.tcsh (http://github.com/supergra/tcsh-sublime is 5 years stale and using source.shell)
etc.
Many shells are Bourne-like but we might not actually gain any useful functionality by grouping them under source.shell.bourne.* as they have subtle differences and sometimes incompatibilities. Similarly, many shells are partially POSIX compliant but not fully, and it may be just as unhelpful to group them under source.shell.posix.*. I think it may be best to simply have every shell sit at the same level of source.shell.*

Any new Bourne-like syntaxes written in the future could choose to include reusable contexts from the ShellScript syntax in the same way that the C++ syntax reuses the C syntax.

[Phidica]

Closing now as the PR was merged in 892f4fc.