markup scope names #1036
Comments
|
I wanted to write a proposal about Essentially, something standard for output panels is missing. I thought of
Markup would also fit:
I'm fine with both. There are two approaches to these kinds of scopes: If an error occurs, do you scope the whole line that explains the error as |
|
@rwols: A good extension to my proposal. As those markup scopes are used to show up errors it may depend on the situation whether to markup the whole line or a word only. A linter, debugger or spellchecker should always markup the position of the error as exact as possible which means it should markup the word(s) or character(s) directly, even though there are several per line. Sublime Text will then add a gutter icon for this line if specified via API call. GitGutter as an example adds a region to the first character per line (by default) no matter how many changes were found. This is mainly done to simulate a kind of gutter icons in the minimap. User can set GitGutter to markup the whole line, too. From my point of view, packages which add regions to the whole line should set the From the point of scope naming I could imagine the following distinction:
|
|
I think we can generally classify all messages as |
|
To encourage maintainers of color schemes to support these scopes, could they be added to Sublime Text documentation somewhere? A page that comes up quickly when searching for documentation on scopes is http://www.sublimetext.com/docs/3/scope_naming.html#color_schemes |
Use markup.error to scope diagnostics: In sublimehq/Packages#1036 the usage of - markup.error - markup.warning - markup.info is proposed to be used to highlight dynamically added markups from - linters - spellcheckers - ... These scopes should be used for any new package of that type and should be added to any color scheme. For backward compatibility sublimelinter.mark.error is applied, too, as not too many packages/color schemes support these latest proposals. * Add package name to scope an region_names - scope should match the syntax file and always end with the syntax name. - regions must be unique and therefore the name of a package should be part of the name
|
The markups should be part of the Minimal Scope Coverage |
|
Maybe remove the "gutter" part in the title because this is more general than just for gutter icons. @tomv564 all of the issues tagged RFC are discussing either scope naming conventions or other types of conventions, that will hopefully be added to the the page you referenced. Mostly scope names, however. |
|
I'm finding this issue useful while working on a hidden syntax that I'm working on, used to highlight the compiler output captured via the Build system of the package. But I'm also thinking that logs need some more specific guidelines for scope names. For example, after compiling a source file, the compiler might return various error, warnings, and infor lines like: Most compiler output/log will include reference to line number and column to which a message refers to (which is also what the Build regexs expect to capture, beside the filename). Wouldn't it then be indeed useful to have some scope names that match the expected results of the build system's
Since these are the expected results in Build systems, it would also make sense to define some scope names for them, so that a color scheme can syntax highlight them in ST Console, making them visually easier to read (which is what I'm trying to achieve). Since Build systems allow "specifying the syntax file to use to highlight the build system output panel" via |
|
Markup scopes are meant to mark already highlighted pieces of text, means underline them or render a colored gutter icon. Don't think they are meant to be used as primary scopes in a view even if it is the output of a built-system. In general the goal is to highlight all kinds of source/text with as general usable scopes as possible to enable best user experience with least possible number of scopes need to be addressed by color schemes. With this said, your request is
It could/should therefore be handled as dedicated proposal about how to handle scoping and highlighting the output of the build system or any other kind of output stuff (linters, ...). The effort to put into it, depends on the expected goal of special highlighting outputs. You can easily use existing scopes for syntax highlighting and put a
or
|
|
I'm proposing a few more markup scopes:
|
|
Can we make a decision on these RFC type issues? Or rather can we delineate a standard process for voting/decision-making? Because this now lingers for three years already. Note that these scopes: are implemented in LSP, as well as SublimeLinter. Color schemes have to follow now. In comparison take a look at how Rust RFCs are handled: https://github.com/rust-lang/rfcs#what-the-process-is |
|
I guess the main question is who is to do the final acceptance. Is it within scope of community or does it require a sublimehq member to do so? With regards to your rust link: I guess https://github.com/SublimeText/ScopeNamingGuidelines is what is meant for something like that. The final question is the same. Who can do acceptance? How does it align with official documentation and also with the inofficial one? To be honest, I don't like having 3 (with this repo 4) places of scope documentation. That said, those scopes are straight forward enough for general acceptance. The last one is a nice example of how those could sub-scoped for more special purpose use cases. |
The LSP packages uses the scope /**
* A document highlight is a range inside a text document which deserves
* special attention. Usually a document highlight is visualized by changing
* the background color of its range.
*
*/Not necessarily, but most of the time these are other occurences of the symbol at a given cursor position. In particular, it's possible to distinguish the kind of such a highlight via a corresponding sub-scope (if supported by the LSP server):
This is an example how it can look with the recommended background highlighting style, and a corresponding rule in the color scheme:
I think this Regarding the "unnecessary" and "deprecated" properties from LSP diagnostics (linters) mentioned in the comment above: The corresponding descriptions in the LSP specification are: /**
* Unused or unnecessary code.
*
* Clients are allowed to render diagnostics with this tag faded out
* instead of having an error squiggle.
*/
export const Unnecessary: 1 = 1;
/**
* Deprecated or obsolete code.
*
* Clients are allowed to rendered diagnostics with this tag strike through.
*/
export const Deprecated: 2 = 2;The suggested styles are independent from the color scheme, and a single markup scope is not sufficient to allow dimmed style for various tokens which can use different colors. I think the best way to handle these would require an extension of the Sublime API instead, e.g. for the |
…P Diagnostics and PackageDev Somewhat related discussion: sublimehq/Packages#1036
I recently found the following
markup.scopes in the latest Monokai.tmTheme when looking for some possibly common scopes to mark warnings/errors for a package I am working on (fork of EasySettings)SublimeLinter uses
Proposal
I suggest to extend the default
markup.scope section in the documentation and actively make use of and propose them to be handled by color schemes.For use with diff and vcs
For use with linter or debugger
Motivation
The motivation of this proposal is to define some common markup scopes which can be used by all packages, which need to add some "message" like information to the gutter area or markup some pieces of source and make sure color schemes handle the most basic classes.
I would like to see the day, SublimeLinter does no longer hack all the color schemes to inject its scopes in there. Instead it should use standardized
markup.warning.linterormarkup.error.linterscopes which are handled by all color schemes.The text was updated successfully, but these errors were encountered: