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

[WIP] feat: Setting toggle for mode dependent cursor block color #4596

Closed
wants to merge 20 commits into from

Conversation

ivenw
Copy link

@ivenw ivenw commented Nov 5, 2022

This PR addresses #4298, #1833, #1337 and offering an alternative solution to #2366.

It follows the implementation suggested #4298. As part of this implementation, this PR immediately deprecates the parent theming field ui.cursor.primary and its children, replacing them with the ui.cursor.secondary family, as discussed in #4298.

For demonstration purposes, the only internal theme updated with this change is dracula.toml.

TODO:

  • Update the remaining in-repo themes to the new cursor theming convention after implementation is approved.

@kirawi kirawi added A-helix-term Area: Helix term improvements A-theme Area: Theme and appearence related S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 5, 2022
@ivenw
Copy link
Author

ivenw commented Nov 10, 2022

@the-mikedavis Thought I ping you here since you wanted to look at the implementation in a PR.

Copy link
Member

@the-mikedavis the-mikedavis left a comment

Choose a reason for hiding this comment

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

@@ -337,48 +332,71 @@ impl EditorView {
doc: &Document,
view: &View,
theme: &Theme,
cursor_shape_config: &CursorShapeConfig,
config: &DynGuard<Config>,
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
config: &DynGuard<Config>,
config: &helix_view::editor::Config,

see render_text_highlights which also takes config. This will eliminate the new imports.

@@ -174,6 +174,8 @@ pub struct Config {
pub indent_guides: IndentGuidesConfig,
/// Whether to color modes with different colors. Defaults to `false`.
pub color_modes: bool,
/// Whether the cursor matches the mode as specified by `ui.cursor.insert` and `ui.cursor.select`. Defaults to `false`.
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
/// Whether the cursor matches the mode as specified by `ui.cursor.insert` and `ui.cursor.select`. Defaults to `false`.
/// Whether to theme the cursor according to the editor mode. Defaults to `false`.

Copy link
Member

Choose a reason for hiding this comment

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

We might want to clarify the docs for color_modes too: "Whether to theme the mode statusline element according to the editor mode. Defaults to false"

@the-mikedavis
Copy link
Member

I like the look of this; I think this is a sane way to tackle the cursor scopes 👍

Before we proceed - I'm curious what you think @archseer?

@the-mikedavis the-mikedavis added S-waiting-on-review Status: Awaiting review from a maintainer. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 12, 2022
@ivenw
Copy link
Author

ivenw commented Dec 8, 2022

I am still interested in implementing this. Are we waiting on input from @archseer ?

@gibbz00
Copy link
Contributor

gibbz00 commented Dec 11, 2022

Maybe I'm a tad bit too tired to fully understand this PR, but aren't we overcomplicating this feature?

Correct me if I'm wrong; this PR makes it possible to have specific colors to both primary and regular (secondary) cursor for each specific mode, right?

Why can't we just implement a ui.cursor.{normal,selected,match,insert}.primary?

Where ui.cursor(.mode) is the fallback if primary isn't explicitly set. The only difference in behavior would be that ui.cursor.mode.primary falls back to ui.cursor.mode and not ui.primary.

No complex state driven theming with the editor.cursor-color-mode boolean and no inconsistent fallbacks.

No ui.cursor.secondary.mode key added, this is what ui.cursor does. Allows for users to slowly get introduced to more complex behavior by their own pursuit of the *primary key. Similar to how one can do printf in python without all the public static void main(string[] args), if you get what I mean.

And most importantly; no deprecation of people's theme overrides and breaking changes to each and every theme.

@archseer
Copy link
Member

There was a similar discussion on #2366

@archseer
Copy link
Member

I think this should be solved on the theme level for sure, no user config options

@archseer
Copy link
Member

ui.cursor.{insert,select}.primary seems like a good solution if we can determine what the fallback should be

@gibbz00
Copy link
Contributor

gibbz00 commented Dec 12, 2022

Oh, thanks, must have missed the PR for #1337. Replying here though to preserve the discussion context.

ui.cursor.{insert,select}.primary seems like a good solution if we can determine what the fallback should be

Mmm as @the-mikedavis pointed out in #4298, default fallback behavior for themes is a.b.c falls back to a.b which falls back to a.

If this principle is followed, then ui.cursor.selected.primary should fall back to ui.cursor.selected. This is on the other hand not in line with the current behavior in which ui.cursor.primary overrides ui.cursor.selected. But such a fix would be minor to the themes which choose to leverage primary cursor differentiation: If the ui.cursor.selected property exists, just make sure to create a ui.cursor.selected.primary with the same properties as ui.cursor.priamry. Same thing for match and insert modes.

After reading #2366 on the other hand, it's clear that it's possible to add this feature with no change to current behavior whatsoever. That is; implement ui.cursor.primary.mode and keep fallback behavior consistent. (Opposed to ui.cursor.mode.primary) Meaning; we wouldn't have to also edit each and every theme in the process.

When I come to think about it, I personally am starting to prefer this solution. It explains why ui.cursor.primary is overwriting things as is, in addition to believing it would be a much simpler implementation. So much so that I went a head and successfully tried this myself. It only adds 6 lines to editor.rs, and in so also making it possible to specifically set cursors for normal mode, whilst using a fallback for the rest. (This PR adds 23 lines, the other 9, just for the differentiation parts).

Anyhow, I created a PR where the changes can be viewed, thinking it would be easier than asking for changes in the respective PRs. Documentation updates have also been prepared. #5130

@ivenw
Copy link
Author

ivenw commented Dec 13, 2022

@gibbz00 made very compelling arguments both here and in #5130.

All things considered, I think #5130 is the better solution for now and I'm happy to endorse it.

When #5130 is merged I will close this PR.

@archseer
Copy link
Member

Replaced by #5130

@archseer archseer closed this Jan 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-helix-term Area: Helix term improvements 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.

5 participants