Closed fitrh closed 2 years ago
I invited you to be a collaborator to make contributor a little easier 😌 Thanks for all your work on this. I would suggest the following for the names:
ModeMsg* → Modes*ModeMsg (verbose but consistent with other names)
VisualVisual → ModesVisual
Other than the naming this looks great. Seems like it fixes a lot of outstanding issues. I'm unable to test at the moment but am curious if tests are passing or need updated with these changes?
I don't have a strong opinion, so I implemented all the suggestions.
In https://github.com/mvllow/modes.nvim/pull/30/commits/e98c8298732dd2eec96c6a01cb42374fac3f97db, I've removed ModeMsg
from winhighlight
, I just realized (because I always turn off showmode
) that ModeMsg
is not affected by winhighlight
.
VisualVisual → ModesVisual
Actually we already have ModesVisual
(using config.colors.visual
), so I named it ModesVisualVisual
(using blended_color.visual
).
I'm unable to test at the moment but am curious if tests are passing or need updated with these changes?
Yes, the tests passed, maybe in the future we need to add more tests.
I did need the M.define()
call within the setup function for cursorline highlights to be applied when using Rosé Pine (dark mode). Otherwise, running :colorscheme rose-pine
was needed to refresh the colors.
I did need the
M.define()
call within the setup function for cursorline highlights to be applied when using Rosé Pine (dark mode). Otherwise, running:colorscheme rose-pine
was needed to refresh the colors.
Sure, seems some lua color schemes don't trigger ColorScheme
events anymore, I did not notice as I handle my color schemes manually and always trigger Colorscheme
events.
No issues after using this branch for the last few days 😌 Thanks for working on this 💜
Putting a rough implementation here to get some feedback if anyone is interested
The current implementation of how we handle the cursor line color for each mode is to override the
CursorLine
highlight group, which leads to the following issues/limitations (at least for me):Assuming that
CursorLine
andCursorLineNr
havebg
Related issue: #16 https://github.com/mvllow/modes.nvim/blob/1086d94b1f7d6ba105593a1dd21e2cb02ab92fc0/lua/modes.lua#L76-L77 Depending on the color scheme, we may override the default color in NORMAL mode if the highligh group does not havebg
(although we haveconfig.set_*
as a workaround)https://user-images.githubusercontent.com/55179750/172336733-d67c0a96-0530-42eb-a0a8-afa9835810b5.mp4
We can not override the highlight groups on the fly for testing purposes Related issue: #18 https://github.com/mvllow/modes.nvim/blob/1086d94b1f7d6ba105593a1dd21e2cb02ab92fc0/lua/modes.lua#L40-L46 Since for every mode-switching, we redefine the highlight group using the initial config color
We have a strong opinions about
CursorLineNr
https://github.com/mvllow/modes.nvim/blob/1086d94b1f7d6ba105593a1dd21e2cb02ab92fc0/lua/modes.lua#L41-L43 We assume thatCursorLineNr
the have the same definition asCursorLine
If we open nvim with an initial window that set
CursorLine
, we end up using that definition for NORMAL mode For example, if we open nvim with-c ':Telescope find_file'
, NORMAL mode will use INSERT mode style since insetup()
we are trying to extract color definition fromCursorLine
, as the result, we are using whatever the initial window defined forCursorLine
https://user-images.githubusercontent.com/55179750/172337470-315d8834-77ea-46a9-b806-40f991ab50b2.mp4
This implementation is to address of these problems
By using
winhighlight
option, we have the flexibility to setCursorLine
/CursorLineNr
without overriding it, it is a local-window option, also we can have different definition betweenCursorLine
/CursorLineNr
so color scheme developer has more control to style those components.We don't need to redefine highlight groups for every mode-switcing as it is already been done in
define()
except forModesOperator
(only built-inhighlight-groups
are supported bywinhighlight
).In the meantime, I've removed this lines as I can't find it's usage, but I'm free to add it back
https://github.com/mvllow/modes.nvim/blob/1086d94b1f7d6ba105593a1dd21e2cb02ab92fc0/lua/modes.lua#L161-L164
This implementation provides the following highlight groups
Modes*CursorLine
, map forCursorLine
Modes*CursorLineNr
, map forCursorLineNr
ModeMsg*
, map forModeMsg
VisualVisual
, map forVisual
(sorry for the name)Now user can define any style they want
The default,
CursorLineNr
-CursorLine
have same definitionThe old style,
CursorLineNr
fg -CursorLine
bghttps://user-images.githubusercontent.com/55179750/172339592-7f9502b8-4dfe-4c14-a8fc-58f3dcf09225.mp4
CursorLineNr
fg with blended bghttps://user-images.githubusercontent.com/55179750/172340466-5685579a-799a-4ad9-9375-2904ac9075c6.mp4
CursorLinrNr
fg with different blended intensity bghttps://user-images.githubusercontent.com/55179750/172342587-dee3aac9-8094-4bdc-839f-0840d10181b3.mp4
or
LineNr
with different bghttps://user-images.githubusercontent.com/55179750/172342137-f6c11e4e-d165-4d2e-bd77-64ed93b70674.mp4
In addition of these changes, this implementation also changes this behavior:
Opens a split window with the same buffer and view port, the VISUAL style is only applied to the focused window
If this change is accepted, there are a few things I'd like to change in this PR (or in the future PRs):
CursorLineNr
(fallback toLineNr
,Normal
) background to use forModes*CursorLineNr
blended color If the color scheme has a different background to it, user still get nice blended color if they use the default stylesI've been using this for a week and it seems to work, but it would be helpful if anyone could help test it.