Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Annotation Style Options #27

Open
bonzairob opened this issue Sep 12, 2019 · 4 comments
Open

Annotation Style Options #27

bonzairob opened this issue Sep 12, 2019 · 4 comments

Comments

@bonzairob
Copy link

bonzairob commented Sep 12, 2019

Would it be possible to add more styles for the annotations? I'd really love to be able to colour the whole line that contains #TODO, in addition to the TODO bit. An additional colour scheme scope for the whole line would be perfect.

@kaste
Copy link
Contributor

kaste commented Sep 12, 2019

Each error can have exactly one style in SublimeLinter, a different style for the line and the word TODO is not possible.

Since these lines would contain whitespace only outline or filled styles would work as well. T.i no underlines etc. Don't know if that would look great or acceptable.

For the implementation, behind a flag in the settings, you would have to implement reposition_match which gets the line and col of the error and returns line, startcol, endcol. This is more or less straight forward if you look at the base method in SublimeLinter or e.g. in the flake8 plugin.

@FichteFoll
Copy link
Collaborator

For the record, I suggested this on the forum.

Wouldn't it be nice if run could also return LintMatch objects? That way custom linters wouldn't need to fabricate some output that is then handed through parse_output -> parse_output_via_regex -> (find_errors -> split_match) and could proceed to process_match directly?

@kaste
Copy link
Contributor

kaste commented Sep 12, 2019

Short term, you could just implement find_errors and yield LintMatch'es t.i. it should not be necessary to implement run. run actually is the entrypoint to the popen thing and ideally would be a separate class/object.

Mid term: Parsing and finalizing are still mixed concerns in Linter. Both filter_errors and process_match finalize the regex matches (LintMatch) and should be factored to the backend, or the backend delegates to another module. In the end, lint should probably just yield LintMatch'es then you could just implement lint and be done with it.

@kaste
Copy link
Contributor

kaste commented Sep 12, 2019

The original feature request could also be an add-on. You just listen for on_lint_result and whenever you find an error you're interested in, e.g. when it's an annotations error, you read it's region expand it to the line and draw another region with a different scope and in your control on top of it. Could be a ten liner 😁

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Development

No branches or pull requests

3 participants