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
[RDY] hl-Syntax should override cursorline and cursorcolumn #6380
Conversation
f794e72
to
ea23b04
Compare
Does this also preserve the text color for concealed characters when |
I don't quite understand your concern since it involves "conceal", "list", "cursorline". Could you give me an example? |
Oh I feel dumb now. You fixed it in #4744. I disabled |
ea23b04
to
e5aafd8
Compare
Just tried this PR (9bc7715). It regresses e.g. the
But the changed diff lines don't show white foreground anymore. |
This is intended. Do you think |
There wouldn't be any purpose to DiffChange if it gets overridden. If colorscheme or user wants DiffChange foreground color to be "overridden", they can do that by not specifying ctermfg/guifg:
If we take that away we've lost flexibility. We don't want to do that for any case where it's already controllable. (So if there are any other cases of this, same principle applies) |
Yes. I have already restored the old behavior of Diff*. |
e5aafd8
to
ecd74d4
Compare
Just did a refactor so that it maintains old |
7ece468
to
5ae213c
Compare
5ae213c
to
53ada62
Compare
Is this patch ready to go? |
53ada62
to
ef6dda1
Compare
@justinmk I fixed some merge conflicts. Is there anything prevent this from being merged? |
ef6dda1
to
95134d5
Compare
&& !(wp == curwin && VIsual_active)) { | ||
if (line_attr != 0 && !(State & INSERT) && bt_quickfix(wp->w_buffer) | ||
&& qf_current_entry(wp) == lnum) { | ||
line_attr = hl_combine_attr(win_hl_attr(wp, HLF_CUL), line_attr); |
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 isn't this branch needed anymore?
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.
The old one basically says if we are in quickfix window, then we use HLF_CUL
to complement current line_attr
, otherwise it will directly set line_attr
to HLF_CUL
. Setting line_attr
to HLF_CUL
is not what we want, since it incorrectly override some highlights under some condition (the logic is complex here)....
In this patch, I split line_attr
into line_attr
and line_attr_low_priority
. Now line_attr_low_priority
only takes care of cursorline
, and it will be merged into char_attr
with lowest priority. For other line_attr
, it will still use the old logic. Since line_attr_low_priority
already has lowest priority, I believe these lines are not necessary.
} else if (draw_color_col && VCOL_HLC == *color_cols) { | ||
vcol_save_attr = char_attr; | ||
char_attr = hl_combine_attr(char_attr, win_hl_attr(wp, HLF_MC)); | ||
char_attr = hl_combine_attr(win_hl_attr(wp, HLF_MC), char_attr); |
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.
This could be a separate change, right? And it's much lower-risk than the line_attr_low_priority
change.
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.
Yes. They can fix the problem for cursorcolumn
and colorcolumn
.
Looking at this again, this adds numerous decisions that appear fragile and difficult to follow.
Is there any way to avoid this? Can we make a smaller improvement with a much smaller code change? |
@justinmk I will say this is unlikely. The old vim uses Also most changes to checks are minor: just replace |
Could you upload a screenshot to describe your problem? |
@zhou13 sorry to confuse, I was referring to the existing behavior, i.e., the behavior I requested we preserve. Nothing changed by this PR. I think ignoring 'cursorline' for diff highlights completely is probably too much, but if we could enable the 'cursorline' highlight only for non-text, that might be interesting. Not sure. Just a thought for the future. |
@zhou13 If you get a chance, it would be valuable to have some test coverage for these changes. I think there's no coverage of 'cursorcolumn' nor 'colorcolumn', and only indirect coverage of 'cursorline'. |
Oh yes. I will work on that.
…On Sun, Oct 8, 2017, 8:26 AM Justin M. Keyes ***@***.***> wrote:
@zhou13 <https://github.com/zhou13> If you get a chance, it would be
valuable to have some test coverage for these changes. I think there's no
coverage of 'cursorcolumn' nor 'colorcolumn', and only indirect coverage of
'cursorline'.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6380 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAjLfoXka7cdEK_8Yzcf9MMdxomiMC0wks5sqOmggaJpZM4MrCy9>
.
|
For reference: this PR was partially reverted, tentative future plan is described in #7383 (comment) |
ref neovim#7383 reverts d1874ab ref neovim#6380
This patch makes syntax highlight correctly overrides 'cursorline' and 'cursorcolumn'
Before this patch (default json syntax highlights every comment as error):
After this patch:
While
nvim -d
or "folding" is not affected (This may be good but I don't know exactly why):