Open KES777 opened 8 years ago
I like this behavior, so a new setting to turn it on and off is good.
This doesn't only affect saving files, it also affects opening files with no extension. There was a short discussion about this on the Default Packages repo which arose from some confusion about the sublime-syntax
file specifying file_extensions
- when in fact it can also be used for the full name of the file.
A number of the default packages use this functionality, especially Ruby
I think it would be better to use a separate key in the sublime-syntax YAML for it, instead of file_extensions
- thus the syntax definitions can be explicit about which are extensions and which are full file names, and not lose any functionality.
I think it would be useful, if/when this gets implemented, if specific filename matching occurred before file extension matching, so that https://github.com/sublimehq/Packages/issues/611 would be possible.
Making a change such as this would be kind of a big backwards compatibility break.
It would be possible to keep the current behavior in file_extensions
and use 2 new YAML keys to prevent backwards compatibility problems. However, it would probably just make it even more confusing...
Another way would be to use the new behavior if the second key exists.
I'm still in favor of separating the two though, despite backwards incompatibility. Cluttering the "save as" window with loads of filenames that happen to use this syntax is kinda bad. However, after the change files still need to be able to be saved with these specific names.
I have a related issue with both ST4 and SM2 where a Python script with filename cs
, no file extension, and a shebang #!/usr/bin/python3
is ending up with an unexpected (at least to me) syntax.
@jfcherng came with this great work around for ST on Discord's #support :
import sublime
import sublime_plugin
class PreferShebangSyntax(sublime_plugin.EventListener):
def on_load(self, view: sublime.View) -> None:
first_line = view.substr(sublime.Region(0, 80))
if first_line.startswith("#!/"):
current_syntax = view.syntax()
target_syntax = sublime.find_syntax_for_file("", first_line)
if target_syntax.path != current_syntax.path and target_syntax.name != "Plain Text":
view.assign_syntax(target_syntax.path)
While it's not exactly what is asked here, this seems like the expected behavior for such cases.
I have a related issue with both ST4 and SM2 where a Python script with filename
cs
, no file extension, and a shebang#!/usr/bin/python3
is ending up with an unexpected (at least to me) syntax.@jfcherng came with this great work around for ST on Discord's #support : ...
By the way, I have that as a part of functionalities in https://packagecontrol.io/packages/AutoSetSyntax.
With regards to this request and the one from #4737, issue #4741 illustrates, why limiting things to extensions (after dots) might be too restrictive.
I like the behavior by matching end of file. It is required to highlight Makefile
itself for example.
But when I save file as php
or r
which are not belongs to php and they are highlighted - this is wrong.
Probably syntax highlighter should be just configured as .php
and .r
. So bare names php
, r
will not be matched
Thus we should not implement new keys, we just need to reconfigure those modules so they will setup .php
instead php
Thus we should not implement new keys, we just need to reconfigure those modules so they will setup
.php
insteadphp
That potentially breaks plugins.
But even with a new key, removing Makefile
from file_extensions
may be a BC break too for a few existing plugins...
Summary
When save files with names such as: 'r', 'pl' syntax is changed
Expected behavior
Syntax is not changed
Steps to reproduce
Environment