ColorHelper adds duplicated (two) colorbox phantoms if a view is splitted

[deathaxe]

Description

Seems ColorHelper has some issues with ST4's new multi-tab features. As soon as a view is cloned into the same group, a second color box appears.

... or a third ...

Support Info

• ST ver.: 4107
• Platform: windows
• Arch: x64
• Plugin ver.: 3.4.0
• Install via PC: True
• mdpopups ver.: 4.1.2
• markdown ver.: 3.2.2
• pygments ver.: 2.1a0
• jinja2 ver.: 2.10.1

Steps to Reproduce Issue

1. Open Sublime Text 4
2. Create a new CSS file
3. Add a color field
4. Right click on view's tab
5. Select "Split View" from context menu
6. see how second color box appears

[facelessuser]

Ugh, yep, confirmed. They must identify as separate views, but share stuff.

@gir-bot add T: bug, S: confirmed
@gir-bot remove S: triage

[facelessuser]

I'm going to need to find a clear way to associate two separate views as being the same view.

[facelessuser]

Okay, I think we can distinguish the two views from each other but still link them back together:

>>> sublime.active_window().active_view().id()
244
>>> sublime.active_window().active_view().is_primary()
False
>>> sublime.active_window().active_view().buffer().primary_view().id()
240

I'm going to have to sit down and go over how to handle this information throughout all the code, but it should be fixable, at least on ST 4081+.

[deathaxe]

In older builds view.buffer_id() is available, which could be used to find associated views or the primary one of a given one. Would need some loops to find those, though.

[facelessuser]

That's a good point. I'll start using the obvious method in 4081+ to see if issues are restricted to previews and where the necessary checks need to be. Once I identify all of that, I can implement a backwards-compatible way.

This shows how often I use clone, but this will be a good bug to get fixed.

[facelessuser]

There is a bug in Sublime. If the primary view of a clone is closed, the clone does not become the primary.

[facelessuser]

I may just need to track previews by the buffer id instead of triggering on whether the view is a clone or not.

[facelessuser]

Looks like tracking previews by buffer id is going to be the fix. This should be backwards compatible as well. That's not to say you can't create some edge cases that will trip up ColorHelper. You could create a clone and set the clone to a different syntax than the primary. Doing so may cause some confusing phantoms in one view vs the other as clones share phantoms, but there is nothing I can really do about that right now. Ideally, the primary would be the source reference for the phantoms, but checking primary support is kind of broken in Sublime.

Anyways, things are looking much better now:

[deathaxe]

If I change the syntax of one view, all clones change accordingly. That's also what I'd expect to happen as syntax should be bound to buffer rather than to a view into it.

[facelessuser]

If I change the syntax of one view, all clones change accordingly. That's also what I'd expect to happen as syntax should be bound to buffer rather than to a view into it.

If that is true for you, that is great. That was not true for me.

[deathaxe]

Nope. That's not happening to me. I tried exactly that and both view's update to the new syntax. Tried both normal and SAFE MODE with ST 4113.

[facelessuser]

Tried both normal and SAFE MODE with ST 4113.

I think you meant ST 4112 unless you have super-secret access to new builds 🙂.

Nope. That's not happening to me.

Again, that is fine. That's just not what I'm seeing.

With all of that said though, the scenario I mention is not a likely one. I wouldn't imagine many people trying to work with cloned views in different syntaxes. If no one else has this issue, maybe it is a local issue with mine, or specific to macOS, who knows.

Regardless, it was an issue for me before the fix and after the fix, so it is nothing introduced with the fix. I'm more noting it as something they may or may not happen, but it sounds like it probably won't affect you.

[facelessuser]

Hmm, yeah, there is something on my system causing this weird issue with different syntaxes selected. Safe mode fixes it. I'll dig deeper.

[facelessuser]

It seems Sublime doesn't actually change the views syntax. When you change one view to a different syntax, calling View.syntax() on the other view will still show its old syntax, even though Sublime ensures the view shows a syntax that matches the other view. So a plugin like BracketHighlighter seems to interfere with Sublime communicating with the other view to make it fake use a matching syntax, and instead, it just switches both syntaxes to whatever is active.

This is weird, and a problem for another day. This syncing of views seems a bit fragile or maybe there is a better way I can manage things in BH 🤷🏻.

[facelessuser]

I'm still inclined to believe there are more Sublime bugs related to clone. Even in safe mode, you can create a primary view and a clone view, change one syntax, and yes they sync up, but close the clone and the primary will still report the old syntax, but show the new syntax.

Here we have a CSS view whose clone was changed to Plain Text. The clone was closed, and while the primary view still shows Plain Text, if you request the syntax (in multiple ways) from the view you get CSS. But test for the scope and you get Plain Text. Things seem a bit buggy with clones in general, so I'm not even sure if it is worth putting in the effort to see why BracketHighlighter may interfere.

Regardless, the filed bug will be fixed, but I am almost certain ColorHelper may run into some bug related to clones weird settings handling.

[deathaxe]

Would probably worth a core issue then, with all the details found.

[facelessuser]

I've added the info to the recent clone issue I created.