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

Integrating with external tools (Hlint - Formatter) #65

Open
emlautarom1 opened this issue Apr 19, 2020 · 5 comments
Open

Integrating with external tools (Hlint - Formatter) #65

emlautarom1 opened this issue Apr 19, 2020 · 5 comments

Comments

@emlautarom1
Copy link
Contributor

Would it be possible to integrate this extension with third-party tools like hlint and some code formatter like brittany or ormolu?

Motivation:
This would improve a lot the UX for new-comers since they don't need to search for a formatting plugin (and which one to use), and having hlint by default would help a lot with learning good practices and new functions (ex. mapM_ instead of _ <- mapM ...)

Considerations:

  • Is this inside the scope of this extension?
  • How would these extensions be handled regarding configs?
  • Should the extension install these tools in case they don't exist?
@dramforever
Copy link
Owner

Is this inside the scope of this extension?

Unfortunately, I don't think so. It feels like integrating hlint or other tools would be a feature that is disconnected from the rest of what the extension does. IMHO these external tools belong in separate extensions.

I can recommend relevant extensions in the README though. The extension pack feature of VSCode might also be helpful to newcomers looking for what to install.

Is there any benefit having a hlint/formatter closer to GHCi that you're thinking about?

@rainbyte
Copy link

It would be cool to have an extension pack around this one, with the best combination possible.

@emlautarom1
Copy link
Contributor Author

emlautarom1 commented Apr 20, 2020

The main benefit is that a single extension would provide what most users expect, instead of segregating the functionality across multiple extensions. For example:

  • Ruby: Intellisense, Semantic Highlight, Code Folding, Code Formatting and Linting
  • Python: IntelliSense, Linting, Debugging, Testing, Environment Management, Refactoring
  • C/C++: IntelliSense, Debugging, Refactoring, Code Folding and Code Formatting
  • Go: IntelliSense, Code Navigation, Code Editing, Diagnostics, Testing, Debugging, Code Formatting
  • Rust (rls): Code Completion, Jump to Definition, Peek definition, Find all References, Symbol search types, Documentation on Hover, Code Formatting, Refactoring (rename, deglob), Error Squiggles, Apply Suggestions, Handle build tasks

All these extensions are in some way "bundles" of features, which most are, in some way, implemented in this extension.

An extension pack would be a solution but it requires that other extensions stay up-to-date and work properly, and also, there are multiple extensions for the same features. For example:

As you can see, there are a lot of extensions. Some provide more functionality than others, and some look like abandoned projects. Integrating one formatter would help a lot to just get-things-done.

Integrating hlint would be pretty cool also, but it's just my personal preference.

@dramforever
Copy link
Owner

@emlautarom1 Yeah, I can see what you mean. It would certainly be nice.

Unfortunately though I don't think it's going to come to vscode-ghc-simple. Integrating all these tools is a maintenance burden, and since I don't really use Haskell all that often, and I don't use most of these tools (presently I use neither hlint nor any formatter), it would mean developing for and supporting things I don't use, which does not sound fun.

Also, from the implementation perspective, my idea of vscode-ghc-simple is that it's supposed to be a 'proxy' between you and GHCi. Instead of reading messages and typing commands in GHCi, you poke around in VSCode instead. Including all the integrations leads the extension away from the idea and its name 'simple'.

I'm not against the idea of an all-in-one Haskell extension, but for now, I don't think vscode-ghc-simple is going to be that. I'm leaving this open for discussion.

@emlautarom1
Copy link
Contributor Author

emlautarom1 commented Apr 20, 2020

I completely understand your point of view and I get that adding new features is a big burden, but for example, code formatting requires < 50 LOC. I made a pull request (#66) so you can check if the added code is worth the hassle.

In case it's rejected and someone ends up in this issue, you should install Ormolu VSCode. It just works!

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

No branches or pull requests

3 participants