Closed michaelblyons closed 5 years ago
This is interesting. I can see why this may be desired. I'm not against it, assuming it can be implemented in a way that makes sense.
I've been looking over issues, and I'm open to implementing this, but before I do, I am looking for discussion and/or proposals as to how this should look.
I've been looking over issues, and I'm open to implementing this, but before I do, I am looking for discussion and/or proposals as to how this should look.
Do you mean a flow chart of what I described in OP, what I think settings should look like, alternative viewpoints, or something else?
Do you mean a flow chart of what I described in OP, what I think settings should look like, alternative viewpoints, or something else?
I'm not looking for a low level design. More high level. I'm looking for how the settings would look.
If you have a proposal of how you'd like to interact with the feature, then I can sort of think through the how that would look under the hood.
I haven't really thought through yet how this would look. Global option. Options per rule. I think once we start spit balling, the weakness should become kind of obvious.
I kind of think this would make since maybe as a global settings, but like I said, I haven' t really thought through this much.
Per rule may be too cumbersome, but if we thought there were some uses cases where that would be helpful, maybe an optional per rule addition? :man_shrugging:.
I think that the place such a feature might annoy people is if the plugin tried to "fix" things that were already fine. I expect those cases to be rare, but if someone (bizarrely?) decided to name their user-config foo.yml.config
and expected you to copy it to foo.yml
.
Then, if a ApplySyntax user with a checkout of that person's repo made a rule that trimmed .config
from the end of all files, it would be obnoxious for other circumstances where you had a traditional file_extensions
set up or a pre-existing ApplySyntax rule.
What I imagine as the most versatile (though feel free to correct me) is something like this:
{
// please let's think of a better setting name
"speculative_path_changes": [
{
// appended dot-suffix files
"match": "(.*)\.[^/\\\\]+\\.(sample|example|orig)$",
"try": "\\1"
},
{
// temporary copies
"match": "(.*)~(\d{1,3}|[a-zA-Z]{6})?$",
"try": "\\1"
},
{
// swap files
"match": "(.*)(/|\\\\)[._]([^/\\\\]+)\\.sw[a-p]$",
"try": "\\1\\2\\3"
},
]
}
I do not know what the performance implications are.
That would be pretty flexible. Do you envision real examples that would require anything more than a simple trim of the last extension? Or at most trimming multiple trailing extensions?
🤔 I don't actually think any "real" cases would need more than a simple trim (and frankly, I even doubt that multiple trims are necessary). Even the [._]*.sw[a-p]
rule (to use gitignore syntax) would probably work as a suffix-only rule.
Yeah, that is kind of what I was thinking. Maybe like you suggest, the path must match some arbitrary pattern, and if it does, the last extension gets trimmed and the file is sent back through the pipe.
You can try out this branch to try the new feature: https://github.com/facelessuser/ApplySyntax/tree/feature/ext-trim.
Feel free to give feedback to help shape it before release. I've done it in such a way that we can potentially extend its capability if we need it in the future, but right now, you just define patterns, and if it matches, the extension will get stripped.
This is a little funky, and perhaps out of scope, but...
I'd like to use ApplySyntax to fix highlighting of merge artifacts† and "sample" files‡. ST obviously doesn't recognize them by file extension, but I was hoping that ApplySyntax could perform a speculative re-application of the syntax application rules with the filename that we would have had without the suffix.
† If I have a merge conflict, I end up with
*.orig
files. (e.g. Conflict infoo.sh
makes afoo.sh.orig
.) ‡ You check out a repository withconfig.yml.example
orcredentials.ini.sample
.