Sublime Forum

ST3: ApplySyntax (was DetectSyntax) new maintainer

#1

I was waiting forever for someone to step up and take ownership of phillipkoebbe’s great plugin DetectSyntax. I wasn’t looking for another plugin to maintain because I have so many as is, but sadly, none of the many users wanted to actually take ownership. So seeing that it may fade away into oblivion (and I actually use this plugin), I decided to take it up. Per phillipkoebbe’s request, I have renamed it to ApplySyntax which makes a bit more sense.

New Repo here:
github.com/facelessuser/ApplySyntax

ST3 Repo:
github.com/facelessuser/ApplySyntax/tree/ST3

I am adding the ST2 repo to PackageControl, and like most of my plugins right now, there is a separate repo for ST3.

1 Like

#2

I pushed a couple of fixes for ST3 version. Should be working better now if you were having issues.

0 Likes

#3

More windows fixes for ST3…now I need to look and see if some of these issues exist on the ST2 version…sigh.

0 Likes

#4

A more sane approach to loading external plugins to determine a syntax has been added to the ST3 branch. This allows for cleaner plugins to ApplySyntax (though I am not really sure if people have written any besides the default is_rails_file.py).

Anyways, paths in the settings file must be Package relative. Example: “Packages/User/my_file” optionally if the plugin is within ApplySyntax you can just use the file name “my_file”. All the other rules still apply with regards to function name vs file name etc. Again, I don’t think many people are using this option, but I decided to clean it up on the ST3 branch.

0 Likes

#5

A new feature for ST3 only has been added to allow Apply Syntax to add extensions to sublime in a more native way.

Adding extensions to the Language sublime-settings file is how Sublime usually handles simple extension association. In the past, ApplySyntax didn’t care about this because there was no real advantage to complying. But with recent versions of ST3, file icons have been added. Post processing the syntax of a file will not show the appropriate icon in the sidebar, but utilizing the built in extension handling for a language can.

…so, ApplySyntax now as an experimental feature to utilize this native extension handling. Ideally, it will replace all the current regex rules that just define extensions:

[pre=#232628] “syntaxes”:
{
“name”: “Makefile/Makefile”,
“rules”:

  •            {"file_name": ".*\\.mak"}
    
  •            {"extensions": "mak"]}
           ]
       },[/pre]
    

Now ApplySyntax will track all of the extensions it specifically adds, so that it can clean them up when the rule is removed or the feature is disabled (this is done automatically and you don’t really need to care):

[pre=#232628]{
“apply_syntax_extensions”:

    "xml.dist"
],
"extensions":

    "svg",
    "xslt",
    "xsd",
    "xml.dist",
    "xml"
]

}[/pre]

The rules can actually coexist for backwards compatibility (though in the future, if all goes according to plan, I will force the extension method by default and remove the old method):
[pre=#232628] “default_syntaxes”:
{
// I put XML first because of files like .tmLanguage. It is unlikely
// that this rule will result in a false positive, meaning if it
// matches, you probably want the XML syntax
“name”: “XML/XML”,
“rules”:
{“file_name”: ".
\.xml(\.dist)?$"},
{“first_line”: “^<\?xml”},
// See “add_exts_to_lang_settings” setting above for more info
// if using extensions, you don’t need to set “file_name”.
// Rule could be simplified to this:
//
// “name”: “XML/XML”,
// “rules”:
// {“first_line”: “^<\?xml”},
// {“extensions”: “xml.dist”]}
// ]
//
{“extensions”: “xml.dist”]}
]
},[/pre]

When defining them the legacy way and the new way, the file, by default is opened correctly by sublime, and then apply syntax checks it again with the regex rule (which is completely unnecessary, but safe).

Now this is only for simple extensions and not for complex file patterns, so there are language cases where you will rightly have regex rules and extensions rules.

Also, it is important to note that when define rule sets with the “match” option set to “all”, “extensions” rules will be ignored in the evaluation. Really extensions is ignored at all times except when ApplySyntax is updating the language settings extensions.

This new feature can be turned on with the following switch:
[pre=#232628] // Auto add extensions to language settings file in User folder. This changes the
// default syntax for a file extension. Keep in mind though that other rules can
// override this. By adding the extension to the language settings file, sidebar
// icons in ST3 will display proper icon for the syntax it will load with
// (assuming another rule doesn’t override the syntax it loads with).
// ApplySyntax will log the extensions it adds under “apply_syntax_extensions”
// to try and track when obsolete ApplySyntax extensions should be removed.
// Do not manually remove “apply_syntax_extensions” from the settings file.
// “extenstions” rules are ignored by “match”: “all” setting.
“add_exts_to_lang_settings”: false,[/pre]

0 Likes

#6

Better logic for experimental extension logic. ApplySyntax now won’t add the same extension to multiple languages, but the last one in the list is the final one. It should also override existing extension settings properly.

0 Likes

#7

After more consideration, extensions has been moved out of rules a level up. So now to define extensions, put them as shown below:

[pre=#232628] {
// I put XML first because of files like .tmLanguage. It is unlikely
// that this rule will result in a false positive, meaning if it
// matches, you probably want the XML syntax
“name”: “XML/XML”,
“extensions”: “xml.dist”],
“rules”:
{“file_name”: ".
\.xml(\.dist)?$"},
{“first_line”: “^<\?xml”},
// See “add_exts_to_lang_settings” setting above for more info
// if using extensions, you don’t need to set “file_name”.
// Rule could be simplified to this:
//
// “name”: “XML/XML”,
// “rules”:
// {“first_line”: “^<\?xml”}
// ],
// “extensions”: “xml.dist”]
//
]
},[/pre]

0 Likes

#8

I have installed sublime and applysyntax.

ApplySyntax file is:

{ "reraise_exceptions": false, "new_file_syntax": false, "syntaxes": { "name": "Perl", "rules": {"file_name": "^.*dhandler$"} ], "name": "Perl", "extensions": "z"], } ] }

but when I open file test.z the syntax type is setted as ‘Plain Text’. Seems pluging does not work.

digging apply_syntax.py I see ‘devlog’ commands.
Please tell me how to turn on something to see ‘devlog’ messages in console?
or tell what is wrong in my config file that syntax is not changed.

0 Likes

#9

In the future, please create issues on the repo.

Your config is probably not getting loaded because you are breaking the JSON spec with the trailing comma.

{ "reraise_exceptions": false, "new_file_syntax": false, "syntaxes": { "name": "Perl", "rules": {"file_name": "^.*dhandler$"} ], "name": "Perl", "extensions": "z"], <--- trailing comma } ] }

For further questions, please create a issue at the github repo.

0 Likes

#10

ok. I will create isuue next time.

but now I answer myself
the ‘name’ must be ‘Perl/Perl’, not just ‘Perl’

0 Likes

#11

Glad you got it figured out.

I am trying to crack down on how people file issues so I can minimize how many times I answer the same question or answering questions that are already documented. I am also updating a lot of my documentation so I can start closing issues that are answered in the docs or are answered in previous issues, but the user hasn’t bothered to read the docs or search the issues. I am hoping that this will force users to read the documentation and in turn help the documentation to improve. Really trying to free up how much time I spend answering issues as I support a lot of plugins.

0 Likes

#12

facelessuser.github.io/ApplySyntax/usage/

Doc says:
“name”: “RSpec”, “RSpec (snippets and syntax)/Syntaxes/RSpec”]

Do you notice “RSpec”? so I use “Perl” and it is not work and I have no any errors in console. I think you must log critical errors in console in any way. This error is critical: Syntax file for Perl does not exist at Packages//Perl.tmLanguage

BUG HERE: if not path continue

Some bug in code? Do you notice double “/”?

(also it is unclear what do you mean under “(snippets and syntax)”. Does it mean specific syntax and will much “RSpec snippets/Syntaxex/RSpec” or “RSpec syntax/Syntaxex/RSpec”. Seems ugly.)

Or you can check “/” in syntax name.
def syntax_apply

+if syntax name not contain “/” then syntaxname = syntaxname + “/” + syntaxname;

Also I recomend you to put into ApplySyntax/Default.Settings
description for “dev_enabled” and “debug_enabled”. There is no any reason to hide them from users.
I also suggest you rename “dev_enabled” to “verbose_debug”

DOCs facelessuser.github.io/ApplySynt … ific-rules says nothing HOWTO make project_syntax. It says that plugin has ability, but nothing to say how to activate that ability (((

0 Likes

#13

Not sure what you mean.

There is nothing to clarify, it doesn’t mean anything, this is literally Rspec’s folder structure. That is the path, it isn’t anything clever on my part.

[quote]Or you can check “/” in syntax name.
def syntax_apply

+if syntax name not contain “/” then syntaxname = syntaxname + “/” + syntaxname;[/quote]

Is this a suggestion? I don’t do it this way as it confuses people. It used to do something similar like this before, and people would mess things up as having multiple ways the name was processed made it more likely for them to screw it up. I answered this question so many times that I just removed it; not adding it back in. Now it is always explicit. I may soon be making it so you have to specify the extension too with the new sublime-syntax becoming a thing. I think this will make it extremely clear what goes in this field. I will probably begin deprecation sometime soon.

[quote]Also I recomend you to put into ApplySyntax/Default.Settings
description for “dev_enabled” and “debug_enabled”. There is no any reason to hide them from users.
I also suggest you rename “dev_enabled” to “verbose_debug”[/quote]

I’m not concerned about the name for “dev_enabled” as it is for me not the user, I’ll consider it, but I don’t mind documenting it.

Again, feature requests and issues should be done on the repo as I cannot track the forum. Issues brought up here often get forgotten because they are not tracked. I see you have started specifying some of your issues there, but please migrate the rest of the discussions there as that is the more appropriate place for them.

0 Likes

#14

can this package work in a new buffer without saving it to file first?

0 Likes

#15

In what respect? Do you want to default new buffers to a specific syntax? Or do you want it to analyze the text in your view buffer and then decide on a syntax? Yes to the first. No to the second.

0 Likes

#16

Thank you for the quick replied. “analyze the text in your view buffer” was what I was looking for.

0 Likes

#17
  { "keys": ["ctrl+alt+s"], "command": "show_overlay",
    "args": {"overlay": "command_palette", "text": "Set Syntax: "} },
2 Likes