Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

completions: Add colors based on the LSP item kind #1905

Closed

Conversation

danyspin97
Copy link
Contributor

This is the result:

20220331_16h18m23s_grim

I was searching for a way to avoiding passing the theme to the row() function, but I couldn't think of anything, I am still new to the codebase. Let me know if there is any better way to to do and I'll reimplement the feature.

I don't have much experience in theming, so I tried to match all the LSP items with a respective parameter of the theme. However, I am not sure that they are all correct, and I have to leave out some of them.

@danyspin97 danyspin97 force-pushed the add_colors_to_completions branch 2 times, most recently from 17aee10 to 45e5938 Compare March 31, 2022 16:05
@danyspin97
Copy link
Contributor Author

Is there anything else I need to do for this PR?

helix-term/src/ui/menu.rs Outdated Show resolved Hide resolved
@pickfire
Copy link
Contributor

Other than the Option thing I think it looks good to me.

@the-mikedavis the-mikedavis added the S-waiting-on-review Status: Awaiting review from a maintainer. label May 18, 2022
Philipp-M
Philipp-M previously approved these changes May 23, 2022
Copy link
Contributor

@Philipp-M Philipp-M left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@danyspin97 danyspin97 force-pushed the add_colors_to_completions branch from 45e5938 to ceacb1c Compare June 9, 2022 13:43
@archseer
Copy link
Member

My holdup here is that with the metadata colorized, it pulls away focus from the actual completions. From what I can tell it's not colorized in VSCode either, instead the icon is colorized.

@danyspin97
Copy link
Contributor Author

Considering the final result from #2190 where the completions have the matching highlighted, I don't think the colors pull away the focus too much. Plus, once I learn the matching color/category, I'd be easier for me to search something in the completion menu. But I'd say that the colored icon would make the same result as well.

@pickfire
Copy link
Contributor

pickfire commented Jul 18, 2022

What if we put a cursor block (like the terminal cursor block) on the left of the metadata with color? That way only one character have color and it looks nice.

<item>              |block| <metadata>
                        ^
                        |
                      color

We could even color the whole metadata by background, that looks nice too but feels like powerline to me and maybe a bit much.

@kirawi kirawi added the A-theme Area: Theme and appearence related label Sep 13, 2022
@kirawi
Copy link
Member

kirawi commented Sep 22, 2022

What if we put a cursor block (like the terminal cursor block) on the left of the metadata with color? That way only one character have color and it looks nice.

<item>              |block| <metadata>
                        ^
                        |
                      color

We could even color the whole metadata by background, that looks nice too but feels like powerline to me and maybe a bit much.

I think we could try that.

@danyspin97
Copy link
Contributor Author

Colored background:
20221209_11h09m57s_grim

Colored blocks:
20221209_11h19m36s_grim

I have tried both method and I think the original one looks cleaner. The one with the background color could look better, providing correct foreground color and better spacing, but I agree with @pickfire that it clutters the interface a bit too much. The other one with the colored blocks doesn't help much for me.

@danyspin97 danyspin97 force-pushed the add_colors_to_completions branch from ceacb1c to 27909d2 Compare December 9, 2022 10:21
@univerz
Copy link

univerz commented Dec 11, 2022

maybe it's more feasible to join forces with #2869 and use the standard solution?

pickfire
pickfire previously approved these changes Mar 26, 2023
Copy link
Contributor

@pickfire pickfire left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the conflict is resolved, I think this is good to go. I think would be good for themes to have choice to style this.

@danyspin97
Copy link
Contributor Author

Rebased the PR :)

Copy link
Member

@dead10ck dead10ck left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not a fan of adding a field to the function signature of the trait just to pepper every single concrete call with an unused parameter, except in one place. I do like the idea of using the theme to decide the color though. Not really sure how else to do it either, since I think it does have to be in the rendering loop. Not really sure if there's a way around it.

.map(|(theme, style)| theme.get(style))
.unwrap_or_default()
.remove_modifier(Modifier::all())
.add_modifier(Modifier::ITALIC);
Copy link
Member

@dead10ck dead10ck Apr 16, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we intentionally removing the modifier from the theme and hardcoding italics? What's the point of pulling in user themes if we're just going to ignore them? I personally can't stand italics in code.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are pulling the theme to apply the colors. This is for the completions items, they should have a matching modifier, i.e. no bold but all in italic. Please have a look at the screenshots above.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, in my opinion, we should just let the theme decide how to style the completion items here and not hard code style for the user.

@@ -33,11 +33,57 @@ impl menu::Item for CompletionItem {
.into()
}

fn format(&self, _data: &Self::Data) -> menu::Row {
// fn label(&self, _data: &Self::Data) -> Spans {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you mean to remove this commented code?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea, this slipped through.

@danyspin97
Copy link
Contributor Author

danyspin97 commented Apr 17, 2023

I'm not a fan of adding a field to the function signature of the trait just to pepper every single concrete call with an unused parameter, except in one place.

It was different before. The function was called row and wasn't used that much over the codebase; so yea, now it looks worse then the original PR and I agree with you. However, I still think this is the most straightforward method. The theme can even be used in other instances of format in the future, that opens up new possibilities if needed.

Another important thing to note is that here the theme is only applied to the items that are shown to the user. To ensure the same, we will still need some way to pass this information from the caller of format.

@pascalkuthe
Copy link
Member

closing this one as its gone stale with many conflicts. I am also working on more completion changes that will conflict even more with this. I am not fundmentally opposed to it but I don't think it adds a lot and is fairly low priority and should probably be deffered until other larger changes are done. Thank you for contributing!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-theme Area: Theme and appearence related S-waiting-on-review Status: Awaiting review from a maintainer.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants