Two color previews showing under certain conditions

[MattDMo]

Description

Build 4112 on Windows 10 x64, regular installer. Latest version of ColorHelper. 2 monitors, not sure if that impacts issue. I'm using a slightly modified version of the SoDaReloaded Dark theme, and my Neon Color Scheme.

The project I currently have open in my main window (there's another window just for SublimeREPL) is split into 2 panes, so I'm viewing 2 files at the same time, one of them being a .sublime-color-scheme. The other one varies, but it doesn't have colors in it from CH. When I start up Sublime with the color scheme pane focused (or focus it quickly before the plugin loads), CH displays normally:

However, if I start up with the other pane focused, when CH loads it shows 2 color previews, the one on the right clickable like normal, the one on the left not:

This is the same if I scroll down through the file and more colors are rendered as they come into view.

I also see this behavior when I click to another .sublime-color-scheme file in a different tab, regardless of whether the startup tab has single or double previews. So, in other words, I start up, the file in view has its previews generated (either single or double, depending on focus), then I click to another tab with a different color scheme, and it always generates double previews.

Now, interestingly, I tested this with a random CSS file, and it only generates single previews, regardless of whether it's focused or not during startup, tab visible or not. I wonder if this behavior is specific to color schemes. I don't have examples of other files with colors in them, but if you have any ideas for other file types to try, I can find some online.

Finally, I scanned through all the startup messages and couldn't find any errors related to CH. If there's a debug mode, let me know and I can enable it. Let me know if you need any other info.

[facelessuser]

I'm betting that this is a duplicate of https://github.com/facelessuser/ColorHelper/issues/187 which already has a fix on the main branch.

[facelessuser]

I've read your message a bit closer, and while I'm not certain if this is a duplicate of the linked issue, it is not quite clear to me how I can go about trying to reproduce.

Can you provide some simple step by steps to reproduce?

It is possible that the unreleased, next version may fix this as I've reworked how previews are done.

[facelessuser]

3 things I do find interesting about your description and screenshots is:

1. The previews are not duplicated in the same spot, but one is outside the quotes and one inside the quotes. This is not at all how things manifested in #187 as the previews were injected into the same spot (inside quotes in color schemes) side by side. ColorHelper should always put the preview precisely beside the color. The fact that the duplicate is not exactly by the color seems out of character for ColorHelper, even if it was creating duplicates.
2. You describe that clicking only one of the previews (the one on the right which is placed where I expect it to be placed) creates a popup, but the one on the left, which seems out of place from how ColorHelper works, does not create a preview. Again, this seems odd but could be because the preview was somehow injected in the wrong place.
3. This is the most peculiar piece of evidence as the previews don't look the same. Comparing them in the screenshot, I can't help but question if you have another color preview plugin running. Note that the one on the left looks smaller and uses a different color border.

@MattDMo Just to test my theory that the secondary previews are not generated by ColorHelper, what happens if one of the colors is a transparent color? I ask this because ColorHelper has a unique way of showing transparent colors that I haven't seen any other color preview plugin do in Sublime. ColorHelper will show a preview half-transparent with a checkerboard background but show half as a fully opaque color. If they do not share the same style, I would begin questioning if you have some kind of LSP plugin injecting previews or some other plugin that also injects color previews in color schemes.

[facelessuser]

I've checked out the latest released tag, tried to create a multi-paned window, and have a view that has no ColorHelper colors focused on startup while showing a pane that should have color previews, and I haven't been able to reproduce. I'm still of the mind that there is something else inserting the secondary previews, not ColorHelper, but without more info, I'm still not sure.

[facelessuser]

I am fairly certain this is not a ColorHelper issue. The secondary color previews seem to have a border that is a slightly different color than the color they represent. We have no code anywhere that would create borders like that.

@MattDMo I will wait for your confirmation, but it is very unlikely that this is not a ColorHelper issue. As things stand now, I think this is a wontfix as there is nothing for us to fix.

@gir-bot remove S: triage, S: more-info-needed @gir-bot add S: wontfix

[MattDMo]

The two preview phantoms do look different with alpha colors:

I'll try disabling as many potential color highlighters as I can, but it's still weird that in some circumstances there's only 1 preview, and in others there's 2. You'd think another highlighter would always be on...

[facelessuser]

@MattDMo while I agree it is weird, as long as ColorHelper's previews are consistently there, that is what I'm concerned with. Any inconsistencies of any other plugin's own previews are under their jurisdiction. Additionally, I do not recommend running other color previewers with ColorHelper as they will produce a very confusing user experiment (this issue a very good example 🙂).

These additional previews seem to place the preview purposely outside the quoted color. I guess that is a personal preference 🤷🏻 . They follow the common approach of most other preview plugins and just show the solid colors instead of also showing how much transparency there is. This is an easier approach, and so I understand why they do it. These differences make it easy to spot that these are not ColorHelper's previews. They are not hooked up to ColorHelper's dialogs as they are not created by ColorHelper, and ColorHelper has no knowledge of them.

I've seen some LSP servers start to do this. CSS is one of them. I believe in most cases these can be disabled. I'm not sure if there are other packages out there looking to add previews as well.

[MattDMo]

I don't purposely have any more color previewers installed, ever since I came across ColorHelper, so I'm going to have to dig to see if I can identify the culprit. Thanks for the LSP tip, I'll start there. I wonder if LSP-json does it...

[facelessuser]

Keep me posted. I just want to make sure there is nothing I need to clean up on this end, though I'm pretty confident at this point this isn't a ColorHelper issue. At the very least, the info you provide may be helpful for others that are surprised by the same issue in the future.

[facelessuser]

@MattDMo It is LSP-JSON. I'm trying to figure out how to disable it now.

[facelessuser]

@MattDMo, Finally have a solution:

Go to Preferences -> Package Settings -> LSP -> Servers -> LSP-JSON and add this:

// Settings in here override those in "LSP-json/LSP-json.sublime-settings"

{
    "disabled_capabilities": {
        // the trigger characters are too blunt, we'll specify auto_complete_selector manually
        "completionProvider": {
            "triggerCharacters": true
        },
        "colorProvider": true
    }
}

[facelessuser]

This info is now in the doc's FAQ section (once GitHub updates their painfully slow cache, but the docs have been updated).

[MattDMo]

Awesome, thanks for tracking that down!