Could C++ header files be given their own syntax?

[iccir]

Currently, if a user wants to show a different file icon for C/C++ header files, a Packages/User/C++.sublime-settings file must be created to remove the "h" extension. See AFileIcon #51 and AFileIcon #97.

Could a separate syntax be created in the C++ package for header files? This would allow for custom header icons as well as custom syntax extensions which only affect headers.

Something like:

Packages/C++/C++ Header.sublime-syntax:

%YAML 1.2
---
name: C++ Header
scope: source.c++.header

file_extensions:
  - h
  - hh
  - hpp
  - hxx
  - h++

extends: Packages/C++/C++.sublime-syntax

Packages/C++/C++ Header.sublime-settings:

{
    "extensions": [ "h" ]
}

[jwortmann]

Currently, if a user wants to show a different file icon for C/C++ header files, a Packages/User/C++.sublime-settings file must be created to remove the "h" extension.

FWIW, such a settings file can also be shipped within the theme package, provided that it already contains a dummy syntax for C++ header files (which is at the moment required anyway if you want to have different icons for .hpp, .h++, etc. files). For example, I do this in my Brackets Theme package: C++ (Header).sublime-settings
That settings file takes precedence over the similar settings file that is contained in this Packages repo, presumingly because my theme package is loaded after the built-in C++ package.

That said, having a dedicated syntax (and removing or modifying the settings file) for C/C++ header files included in this repository would frankly make things easier for theme and icon package authors.

[michaelblyons]

A File Icon builds out those stubs only if they don't already exist. I confess that I don't know all the details.

[iccir]

The existence of any stub files in a theme will break icons in other themes. Per the AFileIcon documentation, themes need to remove all .tmPreferences, .sublime-settings, and .sublime-syntax. AFileIcon will then be the manager of those files and try to smartly add/remove stubs to match the current theme.

It's an absolute mess and I really wish Sublime Text would make it easier for theme developers to support custom icons without breaking each other.

[jwortmann]

This absolutely works, but it has the side effect of breaking icons in other themes.

Sure, but that is a different topic and it wouldn't change if a new syntax for header files gets added to this repository. Any theme package that wants to add a file icon for those header files still needs to provide the .tmPreferences file, and if you then switch to a different theme, file icons would still be broken.

But I don't see that as a relevant issue because it's impossible to use multiple themes at the same time (the "theme" setting is global over all windows), so it's kinda useless to have multiple theme packages installed at the same time anyway. And even in such a case you can still use the "Package Control: Disable Package" command to disable the non-active theme packages.

If a user would like to use some different file icons pack independently of the theme and without the risk of introducing icon conflicts, then Sublime Text probably would need to have separate concepts for regular UI themes and file icon themes, similar to what e.g. VS Code has. But considering the mechanism how file icons are implemented in ST at the moment, I very much doubt that something like that will be introduced in the future.

[deathaxe]

so it's kinda useless to have multiple theme packages installed

Hmm. What's the UI: Select Theme command meant for??? I don't this assumption holds true. I like to switch themes every here and then for instance just based on mood. So any theme breaking others is disqualified to exist on my machine.

[jwortmann]

I like to switch themes every here and then

I assume that most people don't switch their theme regularly. And even if you do that, then I guess you can also afford 5 seconds to run the Package Control: Enable Package command and then Package Control: Disable Package for the previous theme.

Of course it would be nice if there were better and more robust support for file icons in ST (e.g. a simpler way to assign file icons to individual file names), but it is what it is. And my point was that adding a syntax for C++ header files doesn't change anything about that.

[michaelblyons]

Back when I "learned" C++, I put very different things in header files than I did in .cpp files. Is it basically valid to put any C++ in a header? Or just constants and declarations?

If so (or even if someone just wants to make their own opinionated third party package), you could do something like this mockup:

%YAML 1.2
---
name: C++ Header
scope: source.c++.header

file_extensions:
  - h
  - hh
  - hpp
  - hxx
  - hpp

contexts:
  main:
    - include: Packages/C++/C++.sublime-syntax#declarations
    - include: Packages/C++/C++.sublime-syntax#constants

[iccir]

It's completely valid to put any C++ in a header file. Ultimately, the preprocessor concatenates a bunch of header files with your .cpp file and sends that off to the compiler. Often, when dealing with templates, you will have implementations in the header file. See WebKit/Source/WTF/wtf/RefPtr.h for an example of this.

That said, I do something similar to your example (except I extend the Objective-C++ syntax, since I primarily program in Obj-C).