Setting a different color scope

[jrhorn424]

I realize you're busy. Hopefully this is an easy fix.

I'm using the Soda theme, and I'm using Espresso Soda.tmTheme. In that file, there is the following defintion:

    <dict>
        <key>name</key>
        <string>Invalid - Illegal</string>
        <key>scope</key>
        <string>invalid.illegal</string>
        <key>settings</key>
        <dict>
            <key>background</key>
            <string>#F93232</string>
            <key>fontStyle</key>
            <string></string>
            <key>foreground</key>
            <string>#F9F2CE</string>
        </dict>
    </dict>

In my user preferences, I have set:

{   
    ...
    "trailing_spaces_highlight_color": "invalid.illegal",
    ...
}

I'm getting an odd color for trailing spaces that doesn't change, regardless of whether I set the above setting, and regardless of what I set it to. The color I get is like the inverse of Monokai: a pink-bordered black box.

It's pretty jarring with this color scheme, so if I'm doing something wrong, I'd like to fix it.

[jrhorn424]

If I update the setting in the package settings, it works fine. If I comment out the package settings definition, I still get the weird color. I suspect something is going one with the way the plugin loads/respects settings.

[matthewwithanm]

If you put the setting in Users/trailing_spaces.sublime-settings, it should work. (You'll have to create this file.)

[kirbysayshi]

Creating ~/Library/Application Support/Sublime Text 2/Packages/User/trailing_spaces.sublime-settings and adding

{
    "trailing_spaces_highlight_color": "invalid.illegal"
}

worked for me.

But I initially did the same thing as @jrhorn424, and added the line to my user settings file. Is it standard to have to create a settings file per plugin?

[FichteFoll]

Depends on the developer's dicision. As in the code here, this plugin uses a preferences file named 'trailing_spaces.sublime-settings'.

The other way would be to use the view's internal setting (view.settings()) which takes all the other settings like default settings, user settings (probably also plugin settings with that specific file name, i.e. "Preferences"), per-project settings and even per-view settings into account.

[JamesAlday]

My solution is not ideal, but it works... I'm using the Monokai Bright theme and was getting the highlight as a bright pink box - which does bad things to my brain. I tried all of the other color styles in the theme but couldn't get anything but a bright pastel box (lime green, yellow, neon blue, etc). So I just added another dict entry as below:

<dict>
    <key>scope</key>
    <string>trailing.spaces.highlight</string>
    <key>settings</key>
    <dict>
        <key>foreground</key>
        <string>#272822</string>
    </dict>
</dict>

Then, in my trailing_spaces.sublime-settings file I've added:

"trailing_spaces_highlight_color"     : "trailing.spaces.highlight",

Which sets it to be the same color as the dark background of the page. Now the trailing spaces are visible and have a slight reddish/pink outline that's very subdued, which I find very much more agreeable. If I switch themes, this will break, of course. But I have no intention to do so anytime soon, so it's a good solution for now.

It'd be nice if the highlight color would accept a hex code directly instead of or in addition to theme color codes. Thanks to kirbysayshi for the hint on creating the settings file!

[kirbysayshi]

@JamesAlday that sounds like a good feature request, either a new preferences entry to set the color via hex/rgba etc, or adapt the current setting to allow for it.

Perhaps you should open another ticket so it's noticed?

[FichteFoll]

Since ST's coloring works with scopes and colors assigned to these scopes this would require the plugin to auto-edit the current color scheme. It's possible, yes, but since there are actually so many features which require editing the color scheme files (.tmTheme) I wonder how long they won't interfere (with different plugins that is).

[kirbysayshi]

Ah, I didn't realize that, and it sounds pretty dirty to have a plugin edit
a color scheme on the fly.

On Fri, Dec 7, 2012 at 3:15 PM, FichteFoll notifications@github.com wrote:

Since ST's coloring works with scopes and colors assigned to these scopes
this would require the plugin to auto-edit the current color scheme. It's
possible, yes, but since there are actually so many features which require
editing the color scheme files (.tmTheme) I wonder how long they won't
interfere.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/12#issuecomment-11144630.

[FichteFoll]

Well, it actually is dirty but might work out well if there is nothing interfering with your setup. However, if they are two plugins editing the same color scheme (by copying, editing and then assigning the new file to a view) it might get messy and it would be hard to restore the base color scheme file if these plugins are deactivated or the like, unless they use a similar pattern which takes this into account. Unfortunately, I have seen several different approaches on this task and I'm also responsible for at least one of them or their method (that's why I know so much about it) and they do not work together too well. See SublimeText/Origami and FichteFoll/livecss (this one is really dirty).

[rpardee]

FWIW--I created $Packages\User\trailing_spaces.sublime-settings (by doing a save-as on the file of the same name in $packages\TrailingSpaces) and set "trailing_spaces_highlight_color" to an empty string. That has removed the highlighting for me, and the remove-trailing-spaces command still works.

[chikamichi]

@matthewwithanm you are right about it, that it the way to go!

@rpardee thanks for reporting this trick for "invisibility", this is the intended way of doing it actually.

I will edit the README to make it more clear, both cases.

Also, I don't plan to change the way Trailing Spaces' settings are defined (that is, in its specific file) for now.