-
Notifications
You must be signed in to change notification settings - Fork 185
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
show_diagnostics_highlights does not allow styling #1729
Comments
This is a necessary consequnce of a recent refinement for the diagnostics styles (#1710), i.e. errors and warnings always use squiggly style, whereas infos and hints always use dotted style. And this allows to draw multi-line diagnostics as a box without much confusion. It also ensures diagnostics to have a different style than the document highlights (solid underline by default). I guess the squiggly for errors/warnings is what most users would expect/use, so the removal of configuration options here seems to be acceptable in favor of the improvements.
Yes, this is only for the |
Ah, I understand. Is it planned to repair the ability to customize the error/warning (and info/hint) styles? I’m having trouble seeing the various underlines and prefer the box styles with different colors for all diagnostics. |
I don't personally understand the difficulty of adding a customization option that uses the defaults added in #1710 but allows for customization in a setting as before. Lines 32 to 38 in 12de1da
|
Would also really appreciate it if the ability to customize these were restored, I find |
I would also like to have this option as I am used to seeing Here's my first attempt at the preference schema: "diagnostics_highlight_style": { // can be string or object
"oneline": { // can be string or object
"error": "squiggly",
"warning": "squiggly",
"info": "stippled",
"hint": "stippled",
},
"multiline": "box" // can be a string or object like above
} The above shows how to achieve the behaviour that is currently hardcoded into the source, and this could be shipped as default. I am a bit doubtful of this approach if, in the future, more axes are needed for customization. For example, SublimeLinter allows setting the gutter icon too.
Maybe we could use this scheme directly? |
I feel like this nested preference schema is a bit complicated, but in general I'm in favor of having user settings for style configurations too. How about the following suggestion: // Highlight style of code diagnostics.
// Valid values are "box", "underline", "stippled", "squiggly" or "".
// Diagnostics which span multiple lines are always drawn with the "box" style.
"diagnostics_highlight_style": {
"error": "squiggly",
"warning": "squiggly",
"info": "stippled",
"hint": "stippled"
} And if it is set to a string instead of an object, the style applies to all severities (for single-line). That would even be backwards compatible to the former setting (I only removed the "fill" style here, because probably nobody wants to use that for diagnostics - and it would require further considerations when drawn together with documentHighlights). @rwols what do you think?
Note that you can already configure the color, via |
Perhaps you're using hardware acceleration and the squigglies are rendered with 1px? Would restoring it to 2px like in ST3 help with the legibility? sublimehq/sublime_text#4670 |
The squigglies also do not scale along with the |
I would love to be able to customise this option again - one of my main preferences for Sublime rather than VSCode for LSP. |
Describe the bug
The new option
show_diagnostics_highlights
that replaceddiagnostics_highlight_style
does not allow styling the highlights. This is a regression from the earlier feature set where inline diagnostic highlights could be styled to be more easily visible. The settingdocument_highlight_style
only affect other highlights, not diagnostics highlights.To Reproduce
Use the latest version.
Expected behavior
It should be possible to style diagnostic highlights.
Environment (please complete the following information):
The text was updated successfully, but these errors were encountered: