Support "shebang" file header for syntax highlighting override and fallback

[olivierlacan]

Problem description

It's not uncommon for certain languages to have files that are written in that specific language but don't use the typical language extension format.

Ruby has: Gemfile, Rakefile, etc.
Bash has myriad files without .sh.

Sublime tends to throw its hands up and let users fall back to manually choosing a syntax, which is often tedious because there's no way to memorize such settings other than making custom syntax mappings for specific file names.

Preferred solution

Language specific package surely can help normalize syntax highlighting on rare filenames that are common, but Sublime should always allow users to override the syntax highlighting default with a shebang header at the top of the file:

Given a file named .path_alterations:

#!/usr/bin/env bash

function pathprepend {
  case ":$PATH:" in
    *":$1:"*) :;; # path entry is a duplicate
    *) PATH="$1:$PATH";; # prepending to path
  esac
}

Shebang headers are extremely common and even allow the OS to determine whether it can use a specific binary to execute the file as well.

I'm not sure if it would be desirable to override the detected syntax (if the file does have a traditional .rb extension for Ruby for example. This could lead to user error and confusion but could be a useful feature in some cases, maybe.

Alternatives

Relying on custom language packages to define a first_line_match property appropriately, which seems a bit more like a tall order.

This issue is related but not completely overlapping with #1353 which focuses more on an undesirable buggy behavior angle.

[olivierlacan]

I feel like I must have tried this wrong the first time I played with it in Sublime 4 (Build 4107).

Using #!/usr/bin/env/ bash at the top of a Bash file without a typical bash extension (or common filename like .bash_profile seems to work.

I'll close this issue.

[deathaxe]

The behavior you describe is how ST acts. It tries to determine syntax by file extension. If it can't find one it reads the first 2kb of content and matches them against first_line_match of each syntax.

The issue is just not all core syntaxes define a shebang or emacs like pattern in first_line_match. Thus ST may fail in certain cases.

Also see: sublimehq/Packages#2759
An attempt to fix it can be found at: sublimehq/Packages#2760