add Dotfiles Syntax Setter

[snazzybytes]

• I'm the package's author and/or maintainer.
• I have have read the docs.
• I have tagged a release with a semver version number.
• My package repo has a description and a README describing what it's for and how to use it.
• My package doesn't add context menu entries. *
• My package doesn't add key bindings. **

There are no packages like it in Package Control:

• This "Dotfiles Syntax Setter" plugin automatically sets the syntax highlighting to Bash for ALL open dotfiles, enhancing the editing experience for Unix and Linux configuration files.
• It intelligently excludes certain files where Bash syntax is inappropriate, based on a configurable list of exclusions (in some instances known dotfiles are specified in INI, YAML, JSON and other formats).
• It is truly beneficial for those who customize their shell with many separate dotfiles containing custom scripts, aliases, other customizations, etc which are scattered across many files and folders - and are sick and tired of manually setting custom dotfiles to "Bash" syntax everytime

The default configuration excludes various types of files and which be updated as dev tooling grows/changes in the future:

• Configuration files for version control systems (e.g., .gitignore, .gitconfig)
• Editor configuration files (e.g., .editorconfig, .vscode)
• Programming language and environment version managers (e.g., .ruby-version, .nvmrc)
• Linter and formatter configurations (e.g., .eslintrc, .prettierrc)
• Continuous Integration and Continuous Deployment configurations (e.g., .travis.yml, .gitlab-ci.yml)
• Cloud provider CLI configurations (e.g., .gcloud)

In short: "Set Bash syntax for ALL dotfiles - exclude known dotfiles where Bash is actually inappropriate!!!"

[snazzybytes]

@packagecontrol-bot please review

[packagecontrol-bot]

Automated testing result: SUCCESS

Repo link: Dotfiles Syntax Setter

Packages added:
  - Dotfiles Syntax Setter

Processing package "Dotfiles Syntax Setter"
  - All checks passed

[braver]

This project, using a whitelist, already exists: https://packagecontrol.io/packages/Dotfiles%20Syntax%20Highlighting.

Programmatically setting the syntax as your package does risks fighting existing systems in Sublime Text for setting syntaxes, like user preferences. Creating potentially confusing situations for users. I'm not sure how I would implement a blacklist.. did you investigate alternative solutions?

[snazzybytes]

@braver

Investigation

Yes, I looked/checked other syntax plugins and did not find what I am looking for - based on my workflow.

I tried the other plugin you mentioned Dotfiles Syntax Highlighting but I found it is doing things which in my opinion are conceptually wrong: it applies Bash syntax to known dev related files which are actually formatted NOT IN bash syntax, such as INI/JSON and other special configuration files.

In my opinion, I do not want env.local/.gitconfig and similar files to be set to Bash syntax (which are actually in INI-like format) and I am sure this sentiment is common amongst other devs in my situation.

For example, .gitconfig has its own Git Config syntax already in Sublime - yet the plugin you mention would set it wrongfully to Bash (per its whitelist out of the box, which is wrong in my opinion):

Example

• .gitconfig is automatically set to Git Config already by SublimeText and looks pretty
  
• Dotfiles Syntax Highlighting plugin incorrectly would set this file to not look proper/pretty
  

My use case

In my simple plugin approach, I am actually excluding/blacklisting the files which whitelisted by the other plugin - because as I mentioned many of those files are known to be in INI/JSON/other formats and not meant to be highlighted like Bash (hence I carefully came up with an exclusion list of special dotfiles known by different devs depending on nature of their duties).

It comes in especially handy for those who extend their terminal functionality with custom Bash scripts, additional helper functions, and other utilities which are split across multiple dotfiles.

For example in my case, like many others I have $HOME/.dotfiles directory on my machine where such customizations live.
Here is the directory structure and sample dotfile categories to illustrate where I am coming from:

~/.dotfiles  tree -a
.
├── .aiHacks
├── .apiKeys
├── .awsDev
├── .corpDev
├── .cloudCLI
├── .devHacks
├── .iTermCustomizations
├── .macbookUtilities
├── .playground
├── .raspi
└── corp
    └── .apiEntityUtils

Often times I either add new dotfiles into the dir, or open any of the existing dotfiles to add more functions/aliases.
My simple plugin makes it seamless and automatically applies Bash syntax to any new dotfile I drop in there next time I open it up.

With the other plugin in question, it would be very cumbersome because you have to go in and "whitelist" my new random dotfile each and every time which is not ideal because such modifications are spontaneous 😅 (additional manual steps required).

In my SublimeText usage, with my plugin enabled in my User dir - I have not found it to conflict with other existing functionality (that is why I was careful and provided default list of excluded files to prevent such conflicts). This is proven in the above .gitconfig case where Sublime already detects it - but I am excluding it so that Sublime does its thing.

Summary

Hope the above examples and description clears up my reasoning. I will be using my plugin regardless and thought others in my situation would also benefit: the freaks who customize their terminal with many many different dotfiles.

If you think otherwise given the above we do not have to merge this - but this is where I am coming from.
Honestly it already helped me a ton the last couple days (no more manual syntax setting for any new/existing dotfiles from my $HOME/.dotfiles 🙏).

Alrite 🫡

[braver]

Thanks for your thorough explanation!

In my SublimeText usage, with my plugin enabled in my User dir - I have not found it to conflict with other existing functionality

The main thing I'm worried about is if users use the "open files with this extension as" to open a certain type of file with a specific syntax (e.g. toml), that might not work because your plugin overrules that. And the user will just be disappointed, without a clear way to figure out why it doesn't work, or what to do about it. They could customize the blacklist, but then they first need to find out that that's the solution.

I would also say that the current implementation is a bit limited. I use the fish shell for instance, and have many dot files that should have that syntax applied. Or dot files that should be highlighted as toml, or json. Your package doesn't help me there, it only applies bash syntax to hidden files. I also have plenty of files that aren't hidden per se but also don't have an extension (or an identifying first line or shebang), where it would be nice to be able to highlight them some way based on their name.

So, in all, not trying to say it's a bad package, not at all. I'm sure it's a lot more useful than the one already in the registry. But as it is it's also a bit niche, and with a lot of potential for improvement. So yeah, I'm not entirely sure how to proceed. The potential conflict with existing user preferences feels like it should be blocking for release.

[snazzybytes]

The main thing I'm worried about is if users use the "open files with this extension as" to open a certain type of file with a specific syntax (e.g. toml), that might not work because your plugin overrules that. And the user will just be disappointed, without a clear way to figure out why it doesn't work, or what to do about it. They could customize the blacklist, but then they first need to find out that that's the solution.

Just to see what you were saying here, I tried it with random hidden file named .devHacks and then set "Open files with this extension as YAML" (for testing). What happens is it creates YAML.sublime-settings in my User folder with following contents (Sublime is treating the entire dotfile name as an extension itself 😄 ):

{
	"extensions":
	[
		".devHacks"
	]
}

That is true, if the file name started with a .dot it would override their syntax choice there. However it would be strange if a user used "open files with this extension as" on a hidden .dotfile as then the full filename is treated as an extension by sublime 🤔 (it only makes sense for files with an actual extension i.e SomeFileName.extension or .hiddenDotfile.withExtension, not on hidden dotfiles without extension - so I hope user would not apply such sublime settings on their hidden dotfiles without an actual extension on top of it ). Which makes me think your main concern had to do with .hiddenDotfile.withExtension case then right????

Even if the user did misuse the "open files with this extension as" on a hidden dotfile (causing it to be added inside the .sublime-settings json under "extensions" node for given syntax) you could still prevent this from happening.
The plugin would have to scan the User directory for all custom SomeSyntax.sublime-settings files and check for presence of "extensions" node in the json and if present then:
(1) exclude this entry as possible name of hidden .dotfile (accidentally configured via open all files with this extension as)
(2) exclude this entry in case of hidden dotfiles that also have an actual extension i.e .myHiddenDotfile.someExtension

Do you know if there is a way to get Sublime's finite list of possible Syntaxes... so that when checking the User directory for "extensions" in the json - it would only consider syntax related settings instead of unnecessarily checking more files excessively. Otherwise it could still just go through all the User/Something.sublime-settings and rely on presence of "extensions" node in top level of the json. I think this way it would not conflict with the "open files with this extension as" - which was your main concern.

I would also say that the current implementation is a bit limited. I use the fish shell for instance, and have many dot files that should have that syntax applied.

What are the fish-shell dot files. Are those hidden with an extension (like .fishDotFile.some_extension)

Or dot files that should be highlighted as toml, or json. Your package doesn't help me there, it only applies bash syntax to hidden files. I also have plenty of files that aren't hidden per se but also don't have an extension (or an identifying first line or shebang), where it would be nice to be able to highlight them some way based on their name.

Yes, I was blinded by my own routine/ways and thus purely focused just on "Bash for hidden .dotfiles".

In order to accomodate ALL DOTFILES to be configurable for other syntaxes toml or json or other... the plugin logic would have to expand to include a "whitelist" as well (in addition to existing "blacklist"). That is also doable I just requires the precious resource called "time" 😄

I could perhaps squash the "main thing" first which conflicts with existing user settings in my spare time sometime when I am up for it again. Not sure if I would could get the other feature at the same time (the whitelist feature to configure some dotfiles for toml/json/yaml/etc ).

[braver]

Indeed Sublime will use the full filename as “extension” if the file has no extension. That’s useful for all the .eslintrc an .editor-config files etc.

Actually that behavior could be used as an alternative approach for the functionality we’re looking for here: your package could just ship a set of sublime-settings files matching specific “dotfiles” to a syntax. That’s whitelisting, not blacklisting, but with more precision and still allowing users to override the syntax for specific files in the normal way. The package “A File Icon” does something similar.

Another idea I had was that, since you’re applying the syntax after the file has opened, you could also check the file’s syntax before overriding it. You should be able to verify that the file is recognized as “plain text”, meaning that the file has no syntax set either by some other package, or by user preferences. And you could also verify no other syntax has been than “bash”, ie. the user did not specifically set the file to “fish shell” or “toml” etc. In that situation is should be safe to set the syntax to “bash”.

In short, I think this package is really close to what it could be. If we’re really careful about not stepping on work done by other packages or user preferences, it could be really very useful.

[deathaxe]

The package rather looks like a private very simplistic/naive special purpose thing. I don't find it safe to automatically assign Bash syntax to all sorts of dot-files except a limited set of black-listed ones. Use cases for such files are just too many to know and blacklist them all.

The mensioned Dotfiles Syntax Highlighting package applies Bash to .gitconfig files as it hasn't been updated after those have been added to ST's core packages.

Maybe it requires a bit more configuration, but Auto​Set​Syntax should be able to dynamically apply proper syntaxes to all sorts of files, even those not already known by A File Icon.

[braver]

Ok, in its current state, I would say this package is too likely to disrupt normal operation of Sublime Text for its users. There is potential here, but it needs a different approach. Which I can understand if you're not super interested in that, since the package does what it needs to do for you. I don't think it's fit for addition to package control and will close this PR for that reason. Of course, there are other ways to install and distribute packages, and your work could still be someone else's starting point for something more. Thanks for taking the time to submit and work with us during the review.