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

show_diagnostics_highlights does not allow styling #1729

Closed
eproxus opened this issue Jun 8, 2021 · 9 comments
Closed

show_diagnostics_highlights does not allow styling #1729

eproxus opened this issue Jun 8, 2021 · 9 comments

Comments

@eproxus
Copy link

eproxus commented Jun 8, 2021

Describe the bug
The new option show_diagnostics_highlights that replaced diagnostics_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 setting document_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):

  • OS: macOS 11.4
  • Sublime Text version: 4106
  • LSP version: v1.5.0
  • Language servers used: erlang_ls
@jwortmann
Copy link
Member

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.

The setting document_highlight_style only affect other highlights, not diagnostics highlights.

Yes, this is only for the textDocument/documentHighlight request and has nothing to do with the diagnostic styles. For comparison, VSCode draws them similar to the "fill" style, but in ST that only looks well if it is supported/tweaked by the color scheme (as described in the docs under "Customization").

@eproxus
Copy link
Author

eproxus commented Jun 8, 2021

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.

@peterkos
Copy link

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.
The code below is where I found the defaults are being set:

LSP/plugin/core/views.py

Lines 32 to 38 in 12de1da

DIAGNOSTIC_SEVERITY = [
# Kind CSS class Scope for color Icon resource add_regions flags for single-line diagnostic multi-line diagnostic # noqa: E501
("error", "errors", "region.redish markup.error.lsp", "Packages/LSP/icons/error.png", sublime.DRAW_NO_FILL | sublime.DRAW_NO_OUTLINE | sublime.DRAW_SQUIGGLY_UNDERLINE, sublime.DRAW_NO_FILL), # noqa: E501
("warning", "warnings", "region.yellowish markup.warning.lsp", "Packages/LSP/icons/warning.png", sublime.DRAW_NO_FILL | sublime.DRAW_NO_OUTLINE | sublime.DRAW_SQUIGGLY_UNDERLINE, sublime.DRAW_NO_FILL), # noqa: E501
("info", "info", "region.bluish markup.info.lsp", "Packages/LSP/icons/info.png", sublime.DRAW_NO_FILL | sublime.DRAW_NO_OUTLINE | sublime.DRAW_STIPPLED_UNDERLINE, sublime.DRAW_NO_FILL), # noqa: E501
("hint", "hints", "region.bluish markup.info.hint.lsp", "Packages/LSP/icons/info.png", sublime.DRAW_NO_FILL | sublime.DRAW_NO_OUTLINE | sublime.DRAW_STIPPLED_UNDERLINE, sublime.DRAW_NO_FILL), # noqa: E501
] # type: List[Tuple[str, str, str, str, int, int]]

@bakerkretzmar
Copy link

Would also really appreciate it if the ability to customize these were restored, I find stippled much easier to see. I have lots of the other 'boxes' and stuff turned off.

@iamkroot
Copy link
Contributor

I would also like to have this option as I am used to seeing box everywhere.
Before starting to code, it would be worthwhile to figure out how the user can configure this. The old setting only allowed one blanket style for all diagnostics, but now there are 2 axes on which the style can be configured: i) the severity level, and ii) the span of the diagnostic (single line or multiline).

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.
At each level, the user is allowed to either use a string to specify a single value for all its descendants, or manually specify an object for further granularity of control.

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.
Speaking of, it seems SublimeLinter has figured this issue of style configuration figured out pretty well -

  1. It allows setting a stack of styles, each of which can match a set of severities. (If multiple styles match a severity, last one wins).
  2. User can configure the mark_style (box, fill, squiggly, etc), the gutter icon, and the colour.
  3. It doesn't differentiate between single line and multiline, or rather, it automatically overrides the style to box when the diagnostic spans multiple lines. Seems sensible.

Maybe we could use this scheme directly?

@jwortmann
Copy link
Member

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?

2. User can configure the mark_style (box, fill, squiggly, etc), the gutter icon, and the colour.

Note that you can already configure the color, via markup.error, markup.warning, markup.info, markup.info.hint scopes in the color scheme (it uses red/yellow/blue as fallback values if there are no rules in the color scheme) - see documentation, and the gutter icon via the "diagnostics_gutter_marker" setting. And if you want your own gutter icons, or another icon for only a certain severity, you can even do that via Sublime's built-in override mechanism for package files; just set the style to "sign" and create a folder LSP/icons/ in the packages directory, where you put your own files error.png, warning.png, info.png.

@rwols
Copy link
Member

rwols commented Jul 31, 2021

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

@rwols
Copy link
Member

rwols commented Jul 31, 2021

The squigglies also do not scale along with the font_size setting. So users with a 4k screen will see tiny squigglies sublimehq/sublime_text#4561

@munkybutt
Copy link

I would love to be able to customise this option again - one of my main preferences for Sublime rather than VSCode for LSP.

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

No branches or pull requests

7 participants