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

Error underlines and helpfile tweaks #203

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

LunarWatcher
Copy link

@LunarWatcher LunarWatcher commented Jun 11, 2024

TL;DR:

  • ctermul support, in compatible versions of Vim
    • Nvim is not handled because I don't use it and don't feel like looking up what nvim does, and how to test for it
  • Underlines in coc.nvim errors and warnings, using a newly added s:ft_undercurl
  • Specific helpfile highlight groups (as per Papercolor doesn't render helpStars and helpBars properly #161 that I closed for some reason I don't remember) default-linking to Ignore now highlight properly. This is only relevant for helpfile writers, and makes no change for helpfile readers.

Changes

Underlines

One of the problems with most of the current error highlighting is that it disappears when that line is active, at least with set cursorline.
This screenshot demonstrates the current solution:

Pasted image 20240611002436

(Note that the cursor colour is not the default for papercolour; that change is in my vimrc, and not part of this PR)

Note that the behaviour of the background for both warning and error has not changed; without the underline, it's impossible to tell where the error is in a line without first leaving the line. This is annoying while writing code with an LSP

Note that the warning underline being black is not fully intentional, but I couldn't find a colour that worked well with yellow. Using the same colour as the background colour makes the underline have far too little contrast - same with the error undercurl, but s:fg_red exists, so that's a non-issue.

Terminal caveats

In terminal vim, cterm=underline is used instead of undercurl. This is an intentional decision because, for reasons I don't fully understand, setting cterm=undercurl results in no underline of any kind in gnome terminal. Same with ignoring cterm fully and only setting gui. According to the docs, undercurl is supposed to fall back to underline when undercurl isn't available, but I was unable to get this to work within a few minutes, so I didn't bother looking deeper into it. I assume I'm missing something obvious, but I'm leaving this as an exercise for someone else with the patience to figure it out. In either case, the error visibility problem is still fixed even though the type of underline isn't quite right.

Non-GUI and non-256 terminals have also not been handled, and instead gets a blank s:ft_undercurl. I'm not sure whether or not it supports cterm=underline at all, and I'd rather not break anything.

Affected groups

Only coc.nvim's highlight groups have been given underlines. The Error and WarningMsg groups have such wide-spread use elsewhere that underlining them causes multiple theming problems. With s:ft_undercurl, it's easier to add underlines where it makes sense rather than doing the opposite, and removing them from anywhere that didn't expect them.

Ctermul support (... in Vim)

guisp was already implemented, but the equivalent cterm command was left blank. At the time, no alternatives existed. As of Vim 8.2.0863, ctermul exists. This PR adds support for it, with a conditional enable for compatibility using has. This also means ctermul isn't enabled for nvim, which I won't be doing in this PR anyway, because I don't use nvim and I have no clue if it has it, much less how to check if it's present in the current version.

helpBar, helpStar, helpBacktick, and helpIgnore

This change is primarily aimed at anyone writing help documents. Prior to this change (as per #161), these characters were fully hidden. While that is irrelevant for anyone reading help documents, if you write them, it's incredibly annoying to work with nearly invisible characters.

After this change, helpStar, helpBar, and helpBacktick, as well as helpIgnore for the Headers~ and >< blocks are actually visible. For some reason, I couldn't find dedicated syntax highlight groups for ~ and >< - they seem to just be part of helpIgnore, which is why helpIgnore has been highlighted. I've been unable to find any unintentional consequences of this so far.

Pasted image 20240611005349

Note that this screenshot was taken with conceallevel=0 for screenshot reasons. They're still otherwise hidden for anyone reading the helpfile. IIRC, helpfiles have conceallevel set to something non-zero by default, at least when using the :help command1, so this change is only visible when editing helpfiles. This is also when it's useful to have these characters visible.

Footnotes

  1. In addition to conceallevel, concealcursor appears to be reset to nc inside a help document opened with :help, so I'm pretty sure this won't be visible to anyone reading help files.

While counterintuitive, I can't find a way to get cterm=undercurl gui=undercurl to fall back to underline

like the docs say it should do automatically when undercurl is unavailable
Note that this is mainly an observed problem for FernGitStatusWorktree, as it links to WarningMsg, which now has underlines

ErrorMsg is fully undefined, but Error is not, so it shouldn't be a problem

I'm also half wondering if defining Error with s:ft_undercurl was a bad decision
@LunarWatcher
Copy link
Author

LunarWatcher commented Jun 12, 2024

I'm no longer as sure if doing underlines for WarningMsg and Error makes sense, since it's used in other cases where an underline isn't necessarily useful -- maybe it makes more sense to keep it only for LSP diagnostics (i.e. reverting the change to hi Error and hi WarningMsg) to avoid effectively playing whackamole with thematically unwanted newlines? Thoughts, anyone?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant