Add hlint / hdevtools to vim for linter

[tysonzero]

Without hdevtools you won't get typechecking on save, and hlint is needed for any linting beyond what ghc outputs for type errors / warnings. Syntastic basically just makes those tools work within vim / on-save.

Technically they aren't vim plugins themselves, they are standalone executables that syntastic executes and ties into vim, but IMO they should still be mentioned in some way or another.

[rainbyte]

I've added a note about those deps.... Do you think is it adequate?

Maybe it should be indicated in a more general way, without too much specific details, when a certain plug-in needs extra config/deps.

Provide a tutorial for each plug-in is not the intent of this chat... It would be better if they could improve their documentation instead.

[tysonzero]

Hmm, so one thing to consider is that syntastic doesn't necessarily HAVE to use hdevtools and hlint, you could just use one of the two or you could use something like ghc-mod. So I'm not sure the best way to say that, but hdevtools and hlint are sort of sub-plugins/configuration of syntastic that also require totally independent standalone executables.

Perhaps you could have each row be one full setup, and then just have the list of things you need to install, not going into too much depth, so like for VIM it would be something like "hdevtools, hlint, vim-hdevtools, syntastic" and I guess the other ones you added "hindent, vim-snippets". And then if someone also had a good setup with ghc-mod put that on another row?

[rainbyte]

I understand what you are saying... What about this:

• Most cases, it would be prefered to create an issue in the plug-in repo asking for better documentation, so the deps would be listed right in the plug-in webpage (we can indicate in some way that extra config is needed, but just that).
• For exceptions, in somes cases we can state which deps are needed (e.g. for non-Haskell specific plug-ins, like syntastic and yasnippet)

[rainbyte]

I don't want to sound rude, but even in this case, syntastic could provide some hints on which is needed to make it work with Haskell.

What about creating an issue on their bug tracker? Documentation can be improved, win-win :)

[tysonzero]

The documentation explains just fine what the checkers you have to choose from are. hdevtools, HLint, or Style scanner, with links to the respective downloads / docs. The issue is that you have to make a conscious choice between them, which the docs does not and should not make for you, and depending on which you choose that will affect quite a few other things (vim-hdevtools obviously needs hdevtools, other plugins rely on hdevtools or ghc-mod).

IMO you sort of do need to mention hdevtools specifically (and the plugins that work with it, as they do differ from the ghc-mod plugins) outside the syntastic docs.

[rainbyte]

Maybe I'm not understanding this issue correctly. Why syntastic cannot explain that info on their documentation o provide some hint inside vim? This does not mean that they have to choose instead of you.

I'm reading syntastic-checkers..txt, and it does list the options, but does not tell if they are compatible between them (perhaps they work well together?).

From my point of view, this could be taken as low level of support, because it needs manual intervention without giving hints... The plug-in could even ask you via a tooltip, right inside the editor, to install the deps.

Let's see if more people can state their opinion here.

[tysonzero]

They tell you in the README that you need to install a language specific linter to make the linting work, then they give you the linters available for Haskell. That seems pretty complete to me, you pick one or more and install them and use them.

README requirements section:

"Last but not least: syntastic doesn't know how to do any syntax checks by itself. In order to get meaningful results you need to install external checkers corresponding to the types of files you use. Please consult the manual (:help syntastic-checkers in Vim) for a list of supported checkers."

Then that manual lists those checkers, so you just install them and it all works out. It even says in the FAQ that if you aren't seeing any errors you probably haven't installed a syntax checker.

I really don't see what it should do differently, the README very very clearly states EXACTLY what you need to do. Install syntastic then install one or more of the supported checkers.

[rainbyte]

Then we only need a reference to syntastic, where that documentation it is already provided.
No need to duplicate it here, the link and an "extra config needed" notice here is enough.

The chart says: "Vim support for linting is provided by syntastic, and it seems to be mature".
What do you think is missing here? The others plug-ins do not needed special treatment.

[tysonzero]

I mean you don't have to have all the plugins that are supported. I personally have 2 of the 3, which gives mature linting, but if you had say just hdevtools then you would not get any style-based suggestions, and if you had just hlint you wouldn't get typechecking. So people might be unsure which of the 3 they want, and it depends, but if they want mature linting support they are going to want hlint and hdevtools (not sure about the other one).

So syntastic is perfectly usable regardless of which plugin you install, but you are only going to get mature linting if you have hlint+hdevtools or perhaps the third one augmenting / replacing one or both of those (probably not replacing hdevtools).

[rainbyte]

You mean that different levels of support could be achieved using this plug-in.

The user could:

1. Just install it ------------- and obtain absent level of support.
2. Add only 1/3 tools ------ and obtain incomplete level of support
3. Add more tools --------- and obtain full mature support

It is clear that a mature level of support could be achieved with this plug-in.
But it needs reading docs and manual intervention of the user.

In cases like this, we could:

1. State that support is mature (max level achievable), and write a note indicating that "manual intervention is needed" (this is what the chart does now).
2. State that support is inmature, even if a better level is achievable, because most users would expect that just installing the plugin should be enough; and also show the note.

Now we have the following note msg (which could be improved):

this plug-in needs special config and/or system deps, refer to its documentation

How could a plug-in provide better support in cases like this?

1. Provide better documentation, which should mention clearly which feature is provided by each dep, and what combinations are valid (so we can refer user to that docs).
2. Provide in-editor information tooltips to notify the user, i.e. it should detect what binary is missing and show a msg asking for user action (maybe docs are nearly not needed at all in this way).
3. Give the possibility to install missing binary directly from the editor if possible (e.g. in emacs, when intero is missing, the user is asked if she want it to be installed, automatically).

The idea of this chart is showing the current state of the tools, so they can improve themselves, and provide users a guide on which plug-in she could use to add one of the features mentioned.
Tthat is why I don't think it a good idea to add too many plug-in specific indications... The user should be able to follow each link and configure each plug-in without problems.

[tysonzero]

Honestly I still think you should put mature and then just mention the two executables.

To me it is pretty darn similar to how Vim-Plug by itself doesn't do much for you and required "further configuration" to get linting and so on, well its a plugin manager so no shit. Whereas syntastic is a linter manager, so yes you do need more configuration to actually lint in the way you want.

So just like how it would be silly to put Vim-Plug and mature, and say "manual intervention needed". And how it would be silly to put immature, and then put a note to say "oh by the way, if you install plugins then you might get more features". I think it is silly to do the same with syntastic.

I think the key point is that hdevtools and hlint are linters, syntastic is a linter manager / a link between linters and vim. You really should be putting hdevtools and hlint, since they do the linting itself, and you should also put syntastic to explain how to make that linting well managed and embedded in vim. For that same reason I don't even think it would be the worst idea to mention vim-plug at some point.

I guess syntastic could put in their README that they are essentially a linter manager. Although the second sentence being "It runs files through external syntax checkers and displays any resulting errors to the user" is IMO close enough, plus all the rest of the README repeatedly states in different ways how the linters are external and configurable.

[rainbyte]

And what about the other plug-ins?

• Should the chart also state the executables needed for each one? Various plug-ins depend on ghc-mod, hlint, etc. It would not be fair to inform this only for syntastic.
• And what about plug-ins which need some config in a file to enable support? Should we describe that as well? Some plug-ins need some kind of "enable-haskell-feature = true".
• What will happen when the plug-ins change requirements and/or config?

If those things are added, this will be more similar to a tutorial, which is not the idea.
I think it is better to have that information in the docs of each plug-in.

The chart should be limited to inform only which plug-in provides which feature.

[tysonzero]

But that is the thing, syntastic DOESN'T provide linting, syntastic provides linter integration, hlint and hdevtools provide linting.

I would say you shouldn't put direct dependencies, as in, "this required this executable, and not having it will make it not work at all". So vim-hdevtools doesn't need to specify hdevtools.

But I would say you should put things that are morally plugins, like hdevtools / hlint for syntastic, where they aren't requirements, since you can have just one or the separate 3rd one and everything works fine, you don't NEED hlint and hdevtools to use syntastic.

Just like with a plugin-manager, if you have no plugins (or linters) at all, then your manager doesn't help you very much, but that doesn't mean that plugins are a requirement of a manager.

syntastic is fundamentally a linter manager, it is not a linter in itself, that is why it is different than vim-hdevtools and others, where hdevtools is a REQUIREMENT, and not in any way remotely like a plugin.

Just please understand, syntastic does NOT lint, it is NOT a linter. It integrates / manages stand alone linters.

[rainbyte]

I understand that syntastic just call these tools, as in the other editor some editor plug-in call these system utilities.

When using vim, you need syntastic as glue for making hlint and hdevtools work.
Hlint and hdevtools doesn't provide vim linting by themselves.
Syntastic is providing vim linting via hlint and hdevtools, which for that purpose are deps.

The same happens e.g. with atom ide-haskell:

• it only has a hard dep with syntax highlight plug-in.
• the rest are optional, it means you do not have the features if you do not read the doc and install them.

If I add deps for syntastic, I should add optional deps for atom ide-haskell, and any other plug-in which achieves support via optional deps.

[rainbyte]

If the user installs the plug-in, and it does work as expected (because some extra dep is missing), I think is a fault of the plug-in.

Plug-in should indicate deps via documentation o some kind of tooltip, otherwise user experience is just bad.

I'm not a vim user, but I would expect some kind of msg from syntastic if dep is missing, something like:

hey, you open a haskell file, but hlint/hdevtools/__ is not installed, please see docs for more info

That's good user experience