Bug: duplicate virtual text with `tailwind` set to `both`

[gwuen]

Describe the bug
When the tailwind option is set to both and virtualtext is enabled, it appears twice. The second virtual text only appears after the Tailwind Language Server is loaded and disappears when it is unloaded.

To Reproduce

1. Install the Tailwind CSS Language Server
2. Install and configure colorizer: user_default_options = { tailwind = "both", mode = "virtualtext" }
3. Open an HTML file in a Tailwind project (e.g., bradtraversy/simple-tailwind-starter) and make sure the language server is loaded
4. Use any tailwind color name and look for the virtual text appearing twice.

Expected behavior
The virtual text should only appear once.

Screenshots

Operating System: Arch Linux (rolling)

Neovim Version: 0.11.2

[gwuen]

I'd have liked to provide a full minimal init.lua, but it's not that straightforward as it includes setting up the language server. If you can't reproduce this, I will try to provide one.

[catgoose]

I think this is intentional because you have both tailwind names and LSP enabled, but I will look into it.

[gwuen]

I think this is intentional

Actually, I'm not so sure. If that were the case, you would expect the foreground and background modes to reflect this behavior as well, but they only display one color at a time.

Additionally, I see the value in the option to show colors from both the default tailwind names and the LSP not in displaying both simultaneously. Instead, the static color list acts as a fast fallback where the LSP isn't available, such as autocompletion buffers.

This is also supported by the update_names option, which "Updates Tailwind 'normal' names cache from LSP results". In this scenario, the two colors shown would always be identical.

[catgoose]

Thanks, I will look into this.

[ctorgalson]

I just happened to run into something like this myself (not in Tailwind). In my case, it's because a css variable name contains a css color name, so I get virtualtext for the variable value, and the part of the name that matches a css color name:

Making a deliberate typo in the variable name results in only a single virtualtext.

Not sure about the Tailwind options, but it looks like it might be settings-based rather than a bug. For my case, I disabled names since nothing I work on ever uses them.

[catgoose]

so what if you using highlighting instead of virtual text? does it show both colors, or is this only an issue with virtual text? This might have been a case I had not tested when rewriting the tailwind stuff.

[ctorgalson]

so what if you using highlighting instead of virtual text? does it show both colors, or is this only an issue with virtual text? This might have been a case I had not tested when rewriting the tailwind stuff.

With highlighting, it did exactly the same thing. So with e.g. --foo-bar-blue: #000033; both the string blue and #000033 had background highlighting with my original settings.

Without looking in the code (and without really knowing lua--feel free to ignore!), it looks like it might be matching any color name at all, regardless of word-boundaries (e.g. something like /name/ instead of /\bname\b/...)

[gwuen]

I think we're talking about two different issues here. In one case, the plugin is just too aggressively matching every color name without any regards for the context.

In my case, the extension is showing a color hint twice for exactly the same string (only from different sources). There may have been a third color hint if I had normal color name matching enabled (i.e., red, green, blue …), but this is something I would expect in a way.

@catgoose to answer your question: No, with highlighting all looks fine. My guess is that even if the plugin tried rendering both color hints, only one would be visible (probably the last one?). But with virtualtext, the hints are shown next to each other.

[ctorgalson]

@gwuen we might be. I just wanted to point out an instance of a similar behaviour in case they were related.

(Added: the main difference seems to be that in one case the matching is too enthusiastic, but in both cases, it does look like it's matching multiple values--like the TW name and its value--and rendering every match).

[gwuen]

but in both cases, it does look like it's matching multiple values--like the TW name and its value--and rendering every match

Yes, but in the case of Tailwind this is totally intended, while one should take precedence. The document color provided by the Tailwind LSP is more accurate but much slower and not available in every buffer (for example the nvim-cmp popup). The result from the built-in static list should serve as a fallback.