Sublime Forum

SublimeLinter 4 beta

#21

You basically fork the template and tweak it to match the interface of the linter program you want to use.

1 Like

#22

Ok, my issue is, how do I go about creating a ā€œlinter programā€ to interface with in the first place? I guess this would go beyond the scope of SublimeLinter, but this is what I have no clue figuring out, so was hoping someone could give me pointers about.

0 Likes

#23

I was afraid youā€™re going to say that. This is not the right place for that question, I think you could try stack overflow. Also, most linters are open source, so you can start from one of those. Youā€™re not going to find a 101 that will help you get one going without a serious time investment if you donā€™t already know where to start.

2 Likes

#24

Two things:

  1. Can you update the link in the first post for ā€œall the details hereā€ to master from next (now that next is gone)?

  2. The change from .sublimelinterrc to *.sublime-project is really great!! But I canā€™t find any documentation for it.

    I finally found a bug report where someone had posted their Project file with its SublimeLinter section, and I was able to work out what to do. Itā€™s really simple when you see an example, but nigh impossible without knowing the format. Is there a place where the new override syntax is documented?

0 Likes

#25

When sl4 is released the docs at SublimeLinter.com will be updated, but you can always read the current docs in the docs folder of the repo: https://github.com/SublimeLinter/SublimeLinter/blob/master/docs/settings.rst

2 Likes

#26

Just as a heads-up: SublimeLinter 4 is imminent. Possibly this Friday. If youā€™re scared, opt out asap, otherwise: LINTER IS COMING!

2 Likes

#27

Alright, weā€™re live, 4.0 is out there right now. If youā€™re having problems, check the issues for the current status and possible work arounds. Mostly restarting Sublime Text helps a lot, so do that at least twice :smiley:

1 Like

#28

I feel like something is wrong with the font used in the tooltip.

2 Likes

#29

Iā€™ve figured that one out. I had font_face setting set to font that I didnā€™t have on my system (Hack). While the editor itself has fallen back to a default, seems like tooltips donā€™t have the same fallback logic. Solution was to remove that setting.

2 Likes

Change font in the tooltip - sublime linters
#30

How do I disable this in the status bar as I like to keep my status bar minimal.

1 Like

#31

Hey, I donā€™t think we have a setting for that actually. Iā€™ll look into adding that.

1 Like

#32

Thank you :slight_smile:

0 Likes

#33

Just pushed out 4.0.3, should land any minute now with options to completely tweak how and if we show stuff in the status bar!

3 Likes

#34

Works like a charm thank you.

1 Like

#35

guys how i can actived my ignore warning list?

       "htmltidy": {
            "@disable": false, 
            "args": [], 
            "excludes": [], 
            "ignore_match": [
                "missing <!DOCTYPE> declaration", 
                "inserting implicit <body>", 
                "inserting missing 'title' element", 
                "trimming empty <span>"
            ]
        }

and i try add my tidyConfig.txt in arg but nothing =
"args": ["-f tidyErrors.txt -config tidyConfig.txt"],

0 Likes

#36

Could you open an issue in the repo? That makes it easier to get more eyes on it.

0 Likes

#37

There have been some requests to provide more background on some of the user-facing changes. So here:

No ā€œ(SL)ā€ color scheme files are generated, in stead relying on common scopes.

Why it had to change:

  • We wanted to introduce flexible, per-linter and even per-error-code colors, a much requested (and awesome honestly) feature.

Why what we had was bad:

  • The user settings isnā€™t actually the only place you can set a color scheme.
  • It was super tricky for color schemes to prevent the modifications.
  • It wouldnā€™t respect the color schemeā€™s colors.
  • It was pretty much impossible to work on color schemes with SL3 installed.
  • Generating color schemes and then editing the user settings means we had to intrude the user space. For instance, writing to the user settings would wipe all comments from it.
  • The way color schemes were modified breaks in new ST builds.
  • New ST builds introduce new features to extend color schemes that are very easy to do by hand.
  • New ST builds generate ā€œcolorishā€ scopes for us.
  • Most color schemes implement the scopes we use now.

So, we had to option to put effort into maintaining what was a really bad idea, with new ST build already making that effort a waste. Or make it work for 99% of cases without any effort.

The context menu is for stuff relevant to the context, so it now only lists the Lint This View command.

The tools menu has been removed.

We had a lot of ways to change settings. How our settings work had to be completely redone. A lot of how we dealt with settings was counter-intuitive and worked completely different from other packages. E.g. it didnā€™t use standard mechanisms to merge the settings, and it used commands to interact with them (which would remove comments from them, really annoying). We were making really big changes here and would basically have to recreate all 5 different ways to modify settings that SL3 had. Or not, and spend that time testing, improving performance and adding other features.

Weā€™re looking at new ways to toggle linters. Because we use normal settings mechanisms we have a chance of doing it right this time.

The settings ā€œignore_matchesā€ and ā€œdemote_to_warning_matchesā€ have been removed. As has support for .sublimelinterrc files or inline settings.

It makes no sense to have something be a warning in SublimeText (or be hidden), but an error on the command line. In the years since most of SL3 was designed most linters have become more mature and now have configuration files, and/or take arguments.

ā€œmake_warnings_passiveā€ and ā€œshow_errors_on_saveā€ are gone

We have a new output panel feature that should be an improvement for most use cases. Weā€™re looking into restoring something like the show_errors_on_save feature now that we have a better picture of the problem it solves.

Other settings that are gone

  • error_color, warning_color

There is no way to implement thes setting without generating color schemes.

  • gutter_theme_excludes

The feature that used this is gone.

  • tooltip_fontsize, tooltip_theme, tooltip_theme_excludes, tooltips

In stead of multiple tooltip themes that are all terrible and settings you donā€™t need, we now have one good theme.

  • wrap_find

The goto command is configurable. Check the keybindings file for the options.

  • rc_search_limit

We donā€™t support sublimelinterrc files anymore.

  • use_current_shell_path

We donā€™t mess with paths so much anymore, which solves a lot of problems for a lot of users, but may require some work arounds on a Mac. Itā€™s not a 100% win, but the outcome is still very positive.

3 Likes

#38
0 Likes

#39

Hi @braver

Why you remove the option ā€œstatusbar.counters_templateā€?
This options is very useful, to understand better the warning and errors in codeā€¦

You can create a identification in files in sidebar to user undestand how files have changes and errors? More or less like vscode.

p.s: Great work!

1 Like

#40

Why you remove the option ā€œstatusbar.counters_templateā€?

We have more fully featured, and more complicated, feedback for each linter, and that didnā€™t match too well with the templating. Iā€™ll think about bringing it back though.

You can create a identification in files in sidebar to user undestand how files have changes and errors?

There is no api to affect the sidebar in any way. So, we canā€™t change the icons or colors to indicate a fileā€™s status like you would in VS Code or Atom.

0 Likes