Do not apply syntax highlight to files without extensions

[KES777]

Summary

When save files with names such as: 'r', 'pl' syntax is changed

Expected behavior

Syntax is not changed

Steps to reproduce

1. Save file with name 'r'
2. The 'R' syntax is applied to file

   Environment

   • Operating system and version:
   • [x] Windows ...
   • [ ] Mac OS ...
   • [x] Linux Mint 17.3
   • Sublime Text:
   • Build 3114

[evandrocoan]

I like this behavior, so a new setting to turn it on and off is good.

[keith-hall]

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.

[wbond]

A number of the default packages use this functionality, especially Ruby

[keith-hall]

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.

[keith-hall]

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.

[wbond]

Making a change such as this would be kind of a big backwards compatibility break.

[keith-hall]

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

[FichteFoll]

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.

[melomac]

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.

[jfcherng]

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.

[deathaxe]

With regards to this request and the one from #4737, issue #4741 illustrates, why limiting things to extensions (after dots) might be too restrictive.

[KES777]

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

[jfcherng]

Thus we should not implement new keys, we just need to reconfigure those modules so they will setup .php instead php

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