Lightspeed integration about nvim HOT 21 CLOSED

Thanks @jonvaldes :) About the lualine problem, it was just a typo and should be working fine now: 6ad2710.

from nvim.

Actually, the more I'm using this, the more I'm getting used to it... I might even reconsider some choices in the default scheme. It's quite nice that the (normal) labels have background boxes, for example.

if possible, could you PR a better look for the two more problematic ones?

Sure, but I think I have to experiment a lot, I really want this to look good now. :)

from nvim.

Oh for sure. I'm not a light speed user myself, so contribs are more than welcome :)

from nvim.

I'll be closing this issue momentarily since there has not been any work done to implement this feature, yet.

Well, the very point of issues is to be open and visible, if they are unresolved and not considered - for whatever reason - as "wontfix". https://drewdevault.com/2021/10/26/stalebot.html.

from nvim.

Wow, that article did help me clarify some things... I'll reopen this issue then 👍

from nvim.

Gorgeous theme indeed. And I confirm the issue with Lightspeed, I'm seeing that too.

As an added issue with highlight clearing, lualine crashes with Catppuccino, and it seems to be because its highlight groups get cleared too.

from nvim.

Consider me a fan...

And maybe a contributor too...

so it would make sense to do the same for Lightspeed too (I'm the author/maintainer).

Awesome mate! I've never used the plugin but would love to create an integration for it.

1...

Oh yeah no problem with that. The way integrations are structure is that they all have a getter function that return the hi groups with the colors and stuff for it. That getter function could simply setup a hook (new) to run: require'lightspeed'.init_highlight()

it clears out the highlight groups of Lightspeed

Hmm which hi groups does Lightspeed uses?

This might not be too pressing, as Lightspeed washes out the highlights underneath the area, like EasyMotion, and its defaults are perfectly okay-ish anyway, especially for the two dark versions

Oh so the problem is not that it makes your plugin unusable but rather invisible while using Light Melya?

But if you think you can come up with some good tweaks, particularly for light-melya, that would be very cool. I'd be happy to assist with anything, if needed.

Of course we can. I just need to know which hi groups your plugin uses. Also, maybe you could provide a screenshot with what you'd want it to look like on Light Melya?

Or I might do a PR

Feel free to do so. Contribs are always welcome :)

from nvim.

Oh so the problem is not that it makes your plugin unusable but rather invisible while using Light Melya?

Well, without proper highlighting the plugin is of course unusable. Lightspeed's highlight groups simply cease to exist after calling Catpucciono's load() function, regardless of the flavor, I just manually called our init_highlight() to test the themes. This is true for other plugins as well.

That getter function could simply setup a hook (new) to run

Yeah, re-initing the highlights in after_loading works. But the whole issue would be more easily fixed by triggering a doautocmd ColorScheme inside load(), so that every plugin that uses the autocommand trick to restore its highlight groups (Lightspeed, Sneak, Hop, etc.) will just work, without custom integration code here.

Also, the flavors should set the background option, as many plugins (Lightspeed included) rely on that. (We decide the properties of certain highlight groups based whether background is dark or light.)

These would be one-liner PR's I guess, but I don't really find my way around in the Catpuccino codebase yet.

That said, this whole load() business is still a bit odd for me. What is the technical reason behind relying on a custom command :CPLoad, instead of being able to just use the native :colorscheme? This is a very odd design choice. Also, one would expect that if some flavor is set in the setup() fn, then at least :colorscheme catpuccino will use that flavor from then on, but that is not the case, it always sets the default flavor. Or alternatively, all flavors should be exposed to :colorscheme, as different themes...

Lightspeed's highlight groups are described here btw, but the actual color tweaking is not the topmost priority. :)

from nvim.

Also, one would expect that if some flavor is set in the setup() fn, then at least :colorscheme catpuccino will use that flavor from then on, but that is not the case, it always sets the default flavor

Yep that was a bug. Everything should be working now: 1123e0d

from nvim.

Also, the flavors should set the background option, as many plugins (Lightspeed included) rely on that. (We decide the properties of certain highlight groups based whether background is dark or light.)

Just added this in the latest commits 👍

from nvim.

Yep that was a bug. Everything should be working now: 1123e0d

Great, thanks! One step closer... :)

Also, the flavors should set the background option, as many plugins (Lightspeed included) rely on that. (We decide the properties of certain highlight groups based whether background is dark or light.)

Just added this in the latest commits 👍

Hmm, I see no effect. Having the following config:

local catppuccino = require("catppuccino")
catppuccino.setup({ colorscheme = "light_melya", })

and then :colo catppuccino (or load()), the background is still dark...

from nvim.

When using CPLoad to load the plugin, everything seems to be working nicely now for me :)

from nvim.

then :colo catppuccino (or load()), the background is still dark...

Hmm isn't that what it's supposed to do? I coded it so that if the bg is bright then set background to light and if it's dull then set it to dark.

Lol, was it supposed to be the opposite in both cases?

from nvim.

My bad, now it's OK, it's light for light_melya, and dark for the others, fixed.

from nvim.

CPLoad was removed in favor of colorscheme, basically because of the reasons you gave. I also gave a short explanation under the commit: ef0ca31

from nvim.

Hey @ggandor, here you go: 581fd69

Could you test it and give some feedback in the colors? I feel like they are okay :)

Btw about this, shouldn't managing events like this one be something that lightspeed.nvim itself should do? I mean, since highlight groups are such an important part of the plugin then It'd be good, wouldn't it?

from nvim.

Cool, thanks! First, I like the overall color balance very much, this is a very good start. It's pleasing aesthetically, but some choices hinder usability a lot though, everything just blends in/together too much. I think we should keep the attributes (bold, underlined, has background or not, etc.) as the original defaults, they are carefully thought through, or at least keep such invariants such as "the shortcuts are the 'inverses' of normal labels" etc. (the background of shortcuts is the foreground color of the labels).

The most problematic ones are, in my opinion: 1. LightspeedMaskedChar should be very dim, and it should not catch the eye. 2. I'd keep assigning the background "boxes" to LightspeedShortcut, or make them more obtrusive in some other way.

Really thanks for putting in the effort, I'll try play with it too when I'll have the time.

from nvim.

Thanks for the feedback :) if possible, could you PR a better look for the two more problematic ones?

from nvim.

I've thought this through, and even though this looks nice, I think we should keep all the attributes as they were in the defaults - I've written down the reasons here.

from nvim.

Hi! Could you reopen this issue? The highlighting system of Lightspeed is more or less settled now, I guess, and the integration should really be updated eventually, to be consistent with the guidelines. I might do a PR sometime, just keep this on the todo list (then maybe some other contributor will also help us out in the meanwhile). Thanks!

from nvim.

I'll be closing this issue momentarily since there has not been any work done to implement this feature, yet.

from nvim.