Provide a mechanism to automatically syntax color files that lack an extension

[yesmar]

• VSCode Version: Latest (1.10.2)
• OS Version: macOS (but any, really)

Steps to Reproduce:

1. Open up any file lacking an extension
2. Observe how it is not syntax colored without human intervention

Problem: Files without an explicit extension are not syntax colored by default. It is not enough to be able to specify (e.g., in user settings) that all files without an extension are assumed to be of a specific syntax.

Desired Result: A modeline embedded early on in a given file (e.g., the first line, or immediately after the top comment) provides VS Code with a developer-provided hint on how to automatically syntax color a given file, even if it doesn't have a file extension.

Modern C++ header files don't necessarily have file extensions. A common example are STL headers, but I frequently create extension-less C++ headers in my own projects. GitHub lets me work around this issue by reading an editor modeline (e.g., Emacs or Vim) I specify at the top of the file. For a C++ header I can specify the following Emacs modeline in a comment and get C++ syntax coloring: -*- mode: c++; -*- (Vim has a similar mechanism, but I opted to go the Emacs route since Vim's is slightly more verbose.)

VS Code should allow me to do the same thing. Right now, I have to click on the language popup in the status bar and set the language manually. I have to reselect the language periodically, and always between editor invocations, which gets annoying real fast.

One question that might arise is what to do if a file with an extension has a modeline specified? If the modeline matches the extension then obviously there would be no need to do anything. If the modeline is different then VS Code could stick with the extension (a sane default) or, if a new config option has been set to true, use the modeline's value instead.

[mjbvz]

The firstLine language configuration may be what you are after: https://github.com/Microsoft/vscode/blob/2f76c44632b0d47ba97f66fbc158c763628e30b3/extensions/python/package.json#L13 Some of of our builtin languages use the shebang on the first line

[yesmar]

That seems promising on first glance but doesn't really work for me because C++ code doesn't use a shebang. A more robust solution would allow me to specify syntax coloring on a per-file basis using, for example, an editor modeline. In any case, the corresponding cpp/package.json has no concept of firstLine.

[woutgg]

I have a similar request. In my case it regards Zsh completion files which are much more readable when shellscript highlighting is applied.

They are commonly prefixed with an underscore but are not otherwise identifiable by name. They do start with a shebang-like line though (#compdef <name>), so it could be added to the firstLine regex, however it feels too 'specific' to do so.

Instead, I wonder if it would be an option to extend the file association syntax in settings files to support such firstLine regex or possibly a more generic construct to detect a modeline like already mentioned.

With such added expressiveness, users would have a more free - 'extension-agnostic' - way to define associations for extensionless files.

[GorNishanov]

+1 for this feature request. Extension-less C++ headers include a comment that allows editor to properly discover the language.

It seems that -- C++ -- (possibly case insensitive) is frequently used in headers to indicate the language.

Here are couple of examples from two different projects:

// -*- C++ -*-

or

//===- llvm/ADT/AllocatorList.h - Custom allocator list ---------*- C++ -*-===//

[YesThatAllen]

The firstLine language configuration may be what you are after

I have a number of files which are generated by a script, they all start Name: and have no file extension, and are best viewed with the language setting of shellscript.

Without the ability to set a default for files without an extension, how would one go about overriding the package.json to include I^Name.* for a given workspace?

[reyes-c1]

Atom already has this. For example:

# atom: set grammar=yaml

at the top of a file with no extension sets the grammar to YAML. You guys need to catch up.

[alexdima]

Let's track in #1800 which would allow for an extension to implement any behavior.