Allow for project files to specify syntax specific settings for that project.

[Ultra-Instinct-05]

Problem description

Currently, it is not possible for applying a specific setting to a file (syntax setting) only within a project.

Preferred solution

Allow for syntax specific settings within projects that will apply that setting to all the specific files only in that project.

A possible solution would be to introduce a new syntax key for project files as follows.

{
    "syntax": [
        {
            "selector": "source.python",
            "settings": {
                // Define any settings for python files that will override global
                // syntax specific settings for Python.
            }
        },
        {        
            "selector": "source.js",
            "settings": {
                // Define any settings for javascript files that will override global
                // syntax specific settings for JavaScript.
            }
        }
    ]
}

Alternatives

One way I could think of would to use on_load_project or the async variant and listen for when a specific project changes and then apply the settings and clear them when the project switches, but IMHO, the above solution presents a much cleaner way of doing things.

What is your use case for this feature.

Let's say I have a Flask application as a project and I want to switch the .html syntax to Jinja2. I have to do this globally. If I work on an Express project that may use Handlerbars or Nunjucks, I have to again switch syntaxes.

If the above feature could be implemented, I could just specify one templating syntax for .html in one project and it would stay HTML for all other projects except for that project.

Additional Information (optional)

1. ST Build 4094
2. Windows 10 Build 18363.

[keith-hall]

Potentially related/solves: sublimehq/Packages#1764

[rwols]

Because the current syntax-specific overrides are based on the syntax implementation file, and not the base scope, it makes more sense to me if this were a map of (virtual) paths to syntaxes:

// path/to/my.sublime-project
{
    "syntax": {
        "Packages/Python/Python.sublime-syntax": {
            // Define any settings for python files that will override global
            // syntax specific settings for Python. 
        },
        "Packages/Javascript/JavaScript.sublime-syntax": {
            // Define any settings for javascript files that will override global
            // syntax specific settings for JavaScript.
        }
    }
}

While we're on this subject, I'd like to mention that there is also a need for folder-specific overrides:

// path/to/my.sublime-project
{
    "folders": [
        {
            "path": "/home/user/workspace/foo",
            "settings": {
                // Define any settings for this `bar` folder that will override
                // the project-specific settings
            }
        },
        {
            "path": "/home/user/workspace/bar",
            "settings": {
                // Define any settings for this `foo` folder that will override
                // the project-specific settings
            }
        }
    ],
    "syntax": {
        "Packages/Python/Python.sublime-syntax": {
            // Define any settings for python files that will override global
            // syntax specific settings for Python. 
        },
        "Packages/Javascript/JavaScript.sublime-syntax": {
            // Define any settings for javascript files that will override global
            // syntax specific settings for JavaScript.
        }
    },
    "settings": {
        // the project-specific settings that apply to all folders in the project
    }
}

Override chain would then be:

• Packages/Default/Preferences.sublime-settings
• Syntax-specific settings in Packages/Default/ (?)
• Packages/User/Preferences.sublime-settings
• Syntax-specific settings in Packages/User/
• .sublime-project settings
• .sublime-project syntax settings
• .sublime-project folder settings
• window.settings() (???)
• view.settings()

[Ultra-Instinct-05]

Folder specific settings overrides may potentially also solve this #207

[AmjadHD]

related: #3932

[timfjord]

Another solution(but a bit more radical) could be introducing the <project_root>/.sublime_text folder that would be treated the same way as the Packages/User folder but be one level up(basically at the top of the hierarchy).

So, for example, <project_root>/.sublime_text/Python.sublime-settings would control Python-specific settings for the given project.

This would also allow specifying project-related commands and (maybe)override some stuff since this folder would behave the same way the Packages/User behaves.

Theoretically, it could be even placed into all project folders to support folder-specific overrides