Obsolete Haskelly

[InstRM]

Currently, some users continue to use Haskelly despite Haskelly being abandoned, for the simple reason that Haskelly comes with 3 toolbar buttons on the bottom.

First, Haskelly has "Load GHCI", which loads the present .hs file to stack GHCI. This is awfully convenient; you no longer have to contrive the filepath and file name and feed it into GHCI.

Second, Haskelly has "Run file", which uses RunHaskell to run the current file.

Third, Haskelly has Quickcheck integration, which is often highly useful.

VSCode-Haskell is the leading Haskell extension in Visual Studio Code. The features above are request and are relatively trivial, needing only a bit of effort with Javascript. VSCH should implement such features, if only to allow VSCH user to fully uninstall Haskelly and avoid potential bugs.

[jneira]

Hi, thanks for the suggestion. Those haskelly actions are really useful.

However the extension and haskell-language-server has some design principles:

• we have most of the ide logic in the server part: this way the features can be leveraged for any editor with lsp support (emacs, vim, sublime, etc)
• the extension does not talk directly with any haskell tool but the lsp server itself, which is the responsible of doing that

We have an issue about the repl integration here: haskell/haskell-language-server#477
About the integration with the build tool (we aim to support stack and cabal equally) we have: haskell/haskell-language-server#113

[InstRM]

I'm new to FOSS, so if I decided to set up a wrapper for VSC Haskell extension, would that be okay? The Haskelly extension to VSC is already screwed up, in that it often loads multiple buttons. Alternately, just setting a toolbar combinator for stack / runhaskell / ghc / quickcheck that is separate from VSC / Haskelly and can be run independently should do the trick.

…

On Sat, Jan 15, 2022 at 5:02 PM Javier Neira ***@***.***> wrote: Hi, thanks for the suggestion. Those haskelly actions are really useful. However the extension and haskell-language-server has some design principles: - we have most of the ide logic in the server part: this way the features can be leveraged for any editor withlsp support (emacs, vim, sublime, etc) - the extension does not talk directly with any haskell tool but the lsp server itself, which is the responsible of doing that We have an issue about the repl integration here: haskell/haskell-language-server#477 <haskell/haskell-language-server#477> About the integration with the build tool (we aim to support stack and canal equally)we have: haskell/haskell-language-server#113 <haskell/haskell-language-server#113> — Reply to this email directly, view it on GitHub <#524 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AXJ62WHDQQ4ZXTBFHUPZZZTUWHVHBANCNFSM5MAXXI3A> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[jneira]

Sure, there is no problem at all, the project has a MIT license allowing copy it (amongs other things)

[jneira]

if you don't mind I am gonna close the issue as the feature requests are already being tracked in the hls repo, thanks anyways