-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Implement cursorline #2170
Implement cursorline #2170
Conversation
Ok, almost everything is done now. Only the discussion point, about Also, this is my first contribution btw, so apply extra scrutiny when reviewing, even though I applied diligence to keep conventions. |
Another thing that would be useful to add is the ability to only show the cursorline in some modes. In Neovim I have it set up to only show the cursorline in insert mode which helps me quickly see what mode I'm in without looking at the status line. |
Tangential, but not orthagonal: The |
Re-using
Although we haven't used different theming based on modes before - doing it with fine-grained scope names might not be the best option (considering crossing the |
Oh, yeah, using |
I'm currently experimenting with themes a bit. For me a separate setting like Regarding the mode switching, I think a more universal solution might be better. You could also change other UI elements, like the status line color. But this is probably out of scope for this PR. |
We do this for selections already and yeah the behavior gets a bit confusing (see #2366) Do we really want to highlight all lines with cursors though? That might get very noisy when editing a lot of selections. I assumed this would only be implemented for the primary cursor |
Agree, doing it for the primary cursor only (and not showing a cursorline when there are multiple cursors) makes more sense. Noted these improvements. But right now, final exams are kinda filling my time. I'll continue working on the PR before the 23rd, you can ping me if I don't. |
Ok, this is how it works currently: There are three new theme keys:
The intention is that a theme can (but must not) distinguish between primary and secondary cursors. If just This all can be toggled by the config option Technically, one of the two |
Now, If I understood @pickfire and @Zoybean correctly, there are these features that could be nice: (1) Only show cursors for primary window (1) could be a config option. Probably the simplest way would be to convert the |
For the primary window yes, but if the same line appear on other windows, show them as well. Since on the same document, the user is editing on the same line. I am thinking enum would be better given that it could have multiple options.
No, don't sync cursorline, but only show the same cursorline on the same window. If a cursorline appears on the first window, on all the window opened with the same buffer, show it. But when user changed to another window on the same buffer, the original cursorline for that buffer is still the same, so now all other buffers will highlight the same cursorline the user is on for all windows. This way, when user input some stuff on the primary window, the characters won't just magically appear in secondary window, there will also be a cursorline for that secondary window so it users that user is on that line, but in a different color. tl;dr my suggestion
|
These seem to overlap too much for me to cleanly separate them in my head, but here is how I would ideally have mine set up (along with my thought process):
This seems distinct from pickfire's answers, so I agree that this would make sense to be configurable along these lines |
Ok, I think I got it. I was confused, because usually, when I open the same buffer in two windows, it's because I'm editing/viewing a large file at two completely different locations. But I can see the use. Other RFCs: (1) ATM I'm just naïvely adding config options. Right now I am thinking about the config option
(Note: I do prefer the current behaviour, since when changing the window, I know in advance where the cursor will be. So I would like to also keep this behaviour.) (2) Also the themeing keys are starting to get out of hand. At least, four are required, any combination of focused / unfocused window and primary / secondary cursor. This puts a relatively high burden on theme porters to support cursorlines IMO. This could be improved by having sensible defaults (ie. inactive colors default to their active counterparts). I'd recommend the following keys:
|
This seems to be getting a bit overengineered: helix is not doom emacs, so it's okay to diverge. In our case each window has it's own set of cursors. We already only show cursors for the current view/active files, so I imagine it would get confusing if cursorlines of all views were rendered but didn't map to a selection. Since the intent is to make it easier to find the main cursor, I think it's sufficient to only render the primary selection's cursorline in the active view. Rendering it on all views pulls eye focus and isn't as easy to figure out which view is actually focused. |
@archseer What about this: config option And these themeing keys:
|
It looks like this errors if (Actually, I have The error only appears (and the theme is not loaded) when |
There's a syntax error because the |
oh, man, that was dumb of me. Thanks. |
for some reason enabling cursorline is causing noticeable lag in scrolling. I just have a bg style set, and it's significantly slower to scroll than when cursorline is disabled. |
It feel slower at first, but I compare it a couple of times, it seemed similar. I guess that's because the whole line is moving and you eyes need to process a lot of stuff. Not sure if it's really slower since I didn't time it to the milliseconds with replay. |
It's definitely slower, but I'm getting used to it. Certainly having the cursorline makes up for the delay. |
I don't notice any slowdown running in release or debug mode and scrolling quickly with a mouse. It might be worth poking around with cargo-flamegraph if it's noticeable. From a quick glance I see |
For #2170 (comment), let's keep @archseer for
were you thinking of only rendering the primary selection altogether (no secondary selections at all), or only highlighting the primary selection as |
helix-term/src/ui/editor.rs
Outdated
if primary_line == line { | ||
surface.set_style(area, primary_style); | ||
} else if secondary_lines.contains(&line) { | ||
surface.set_style(area, secondary_style); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not just highlight primary_line
after secondary_line
after the loop so we don't have to check whether or not it was part of secondary line?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We still have to check for each line
if secondary_lines
contains it, since line
is one of all the lines on the screen, only some will be highlighted.
Strictly speaking, not checking and then just overwriting after the loop might be even (veery slightly) slower, since the comparison primary_line == line
is basically free, but coloring the secondary_line
(which is redundant because it will be overwritten) is less cheap. (I might be wrong though.)
I think we want to provide the ability to highlight both primary and secondary selections, but by default I'd only style the primary selection (users can add their own styling for secondary if they want). |
So make |
To do it without adding an exception to the fallback behavior, we could add a theme just for |
The documentation for |
Highlight all lines where cursers are on, imitating vim's
cursorline
option.See #1761.
Todo:
Improvements:
ui.cursorline[.primary | .secondary]