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

Describes itself as a RubyLinter when it should just be a Linter #5

Open
gerph opened this issue May 30, 2020 · 1 comment
Open

Describes itself as a RubyLinter when it should just be a Linter #5

gerph opened this issue May 30, 2020 · 1 comment

Comments

@gerph
Copy link

gerph commented May 30, 2020

The linter declares itself as a RubyLinter, but when you're running tools you shouldn't care what language the tool is implemented in and the interpreter that should be used to run it. That's what the #! lines are for - to say how you run the tool.

Why is this a problem? Well, the tool called mdl in my path isn't a ruby script. It's a shell script that runs the markdownlint/markdownlint docker container on the command that was supplied. This avoids my having to install ruby and the mdl tool into the environment.

So I have to change the linter.py code from:

class Mdl(RubyLinter):

to

class Mdl(Linter):
@kaste
Copy link
Contributor

kaste commented Jun 1, 2020

That's somehow correct. I too think the RubyLinter implementation is outdated that's why we tried a simplified new implementation for rubocop only supporting "rvm" and "bundle". See https://github.com/SublimeLinter/SublimeLinter-rubocop/blob/master/linter.py#L5-L22

Do you think we should use that here as well?

It is otherwise not necessary to fork just for your use case. You can override the default lookup algo by setting "executable" in the settings. Here setting it to just "mdl" (if it's an executable in PATH) would be enough. (http://www.sublimelinter.com/en/stable/linter_settings.html#executable)

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

No branches or pull requests

2 participants