facelessuser / ApplySyntax

Syntax detector for Sublime Text
https://facelessuser.github.io/ApplySyntax/
343 stars 48 forks source link

"Trim" appended file extensions before running rules. #132

Closed michaelblyons closed 5 years ago

michaelblyons commented 5 years ago

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 in foo.sh makes a foo.sh.orig.) ‡ You check out a repository with config.yml.example or credentials.ini.sample.

facelessuser commented 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.

facelessuser commented 5 years ago

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.

michaelblyons commented 5 years ago

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?

facelessuser commented 5 years ago

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.

facelessuser commented 5 years ago

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:.

michaelblyons commented 5 years ago

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.

facelessuser commented 5 years ago

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?

michaelblyons commented 5 years ago

🤔 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.

facelessuser commented 5 years ago

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.

facelessuser commented 5 years ago

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.