haskell / vscode-haskell

VS Code extension for Haskell, powered by haskell-language-server
https://marketplace.visualstudio.com/items?itemName=haskell.haskell
Other
561 stars 90 forks source link

Support WSL for Windows #99

Closed Ciantic closed 4 years ago

Ciantic commented 6 years ago

HIE, Stack etc. compiles absolutely perfectly from a Windows Subsystem for Linux e.g. the Ubuntu.

I have come to conclusion that majority of Haskell tools will never support Windows adequately, the Stack for instance usually just gives weird errors with some libraries etc. Instead in WSL the Stack, HIE etc. compiles with the Linux instructions and works perfectly.

I have tried to make vscode-hie-server to work with the HIE running in WSL, but I think the only problem is that the HIE running in WSL has paths starting /mnt/C/ instead of C:. The change required is probably not very big.

It shouldn't require any changes to haskell-ide-engine, just some mangling in the vscode-hie-server.

The OCaml Language Server works like this, it just has bat files that starts the binaries in the WSL bash using bash -c ... it allows to translate paths from Windows to WSL format also.

EDIT Yes!

I found a way, I hacked the extension.js source code directly, only thing that is required is to do this in the clientOptions:

        uriConverters: {
            code2Protocol: (uri) => {
                let nUri = uri.toString()
                    .replace(/\\/g, "/")
                    .replace("c%3A", "mnt/c");

                // console.error("code 2 protocol", nUri);
                return nUri
            },
            protocol2Code: function (str) {
                let uri = vscode_1.Uri.parse(str.replace("mnt/c", "c%3A"));
                // console.error("protocol 2 code", str);
                return uri;
            },
        },

Of course you need to set the VSCode settings to following:

    "languageServerHaskell.useCustomHieWrapper": true,
    "languageServerHaskell.useCustomHieWrapperPath": "...\\hie-wsl-wrapper.bat",
    "languageServerHaskell.useHieWrapper": true

Simplest hie-wsl-wrapper.bat can be following:

@echo off
bash -ci "hie-wrapper --lsp"

(One can't use wsl as an executing binary because the bashrc must be run, and bash -ci runs it.)

However, if it doesn't work usually the ~/.local/bin/ is not put in the PATH at the WSL. Besides these it would be good to have few checks so that new users can be guided by the VSCode plugin how to install HIE correctly in the WSL.

I probably will do a pull request sometime for this, my plan is to add a new settings: languageServerHaskell.useWslHieWrapperPath and languageServerHaskell.useWslHieWrapper and provide a default hie-wsl-wrapper.bat.

These could be checked against and the uriConverter could be turned on if they are set. The plugin must guide the Windows users more with clear setup instructions if something seems failing.

pr-ravi commented 6 years ago

Please add this as a pull request, would be quite useful and essential

pr-ravi commented 6 years ago

HIE, Stack etc. compiles absolutely perfectly from a Windows Subsystem for Linux e.g. the Ubuntu.

I have come to conclusion that majority of Haskell tools will never support Windows adequately, the Stack for instance usually just gives weird errors with some libraries etc. Instead in WSL the Stack, HIE etc. compiles with the Linux instructions and works perfectly.

I have tried to make vscode-hie-server to work with the HIE running in WSL, but I think the only problem is that the HIE running in WSL has paths starting /mnt/C/ instead of C:. The change required is probably not very big.

It shouldn't require any changes to haskell-ide-engine, just some mangling in the vscode-hie-server.

The OCaml Language Server works like this, it just has bat files that starts the binaries in the WSL bash using bash -c ... it allows to translate paths from Windows to WSL format also.

EDIT Yes!

I found a way, I hacked the extension.js source code directly, only thing that is required is to do this in the clientOptions:

        uriConverters: {
            code2Protocol: (uri) => {
                let nUri = uri.toString()
                    .replace(/\\/g, "/")
                    .replace("c%3A", "mnt/c");

                // console.error("code 2 protocol", nUri);
                return nUri
            },
            protocol2Code: function (str) {
                let uri = vscode_1.Uri.parse(str.replace("mnt/c", "c%3A"));
                // console.error("protocol 2 code", str);
                return uri;
            },
        },

Of course you need to set the VSCode settings to following:

    "languageServerHaskell.useCustomHieWrapper": true,
    "languageServerHaskell.useCustomHieWrapperPath": "...\\hie-wsl-wrapper.bat",
    "languageServerHaskell.useHieWrapper": true

Simplest hie-wsl-wrapper.bat can be following:

@echo off
bash -ci "hie-wrapper --lsp"

(One can't use wsl as an executing binary because the bashrc must be run, and bash -ci runs it.)

However, if it doesn't work usually the ~/.local/bin/ is not put in the PATH at the WSL. Besides these it would be good to have few checks so that new users can be guided by the VSCode plugin how to install HIE correctly in the WSL.

I probably will do a pull request sometime for this, my plan is to add a new settings: languageServerHaskell.useWslHieWrapperPath and languageServerHaskell.useWslHieWrapper and provide a default hie-wsl-wrapper.bat.

These could be checked against and the uriConverter could be turned on if they are set. The plugin must guide the Windows users more with clear setup instructions if something seems failing.

I'm getting an error
src/extension.ts(178,21): error TS2304: Cannot find name 'vscode_1'

v-garcia commented 6 years ago

@dareTake Strange for me the file in question is extension.js and is located in this folder: C:\Users\%USERNAME%\.vscode\extensions\alanz.vscode-hie-server-0.0.24\out\src\.

Then vscode_1 is assigned on that instruction const vscode_1 = require("vscode"); at the beginning of the file (line ~14). Check that this assignment exists in the file you are editing.

For me, the solution provided by @Ciantic worked well.

AurevoirXavier commented 4 years ago

Can't work on WSL too. And the old HIE plugin move into this project. I can't use any language server now. OMG.

Ciantic commented 4 years ago

These days there are better ways with WSL remoting that just works:

https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-wsl

I highly recommend using WSL remoting instead of the hack I gave above. Because WSL remoting uses the Linux environment in full to run the extensions, it works way better.

I will close this issue, maybe some documentation would still be in order to add, but maybe a new issue for that?

AurevoirXavier commented 4 years ago

These features totally not working.

  1. Formatting via Brittany, Floskell, Ormolu or Stylish Haskell
  2. Code evaluation (Haskell Language Server) I can't see the Evaluate... which was shown in the gif.

I'm sure I already install the brittany and it's in my $PATH.

AurevoirXavier commented 4 years ago

These days there are better ways with WSL remoting that just works:

https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-wsl

I highly recommend using WSL remoting instead of the hack I gave above. Because WSL remoting uses the Linux environment in full to run the extensions, it works way better.

I will close this issue, maybe some documentation would still be in order to add, but maybe a new issue for that?

Yes I'm using WSL remoting.

AurevoirXavier commented 4 years ago

This plugin works well. https://marketplace.visualstudio.com/items?itemName=MaxGabriel.brittany

So my $PATH is OK.

But isn't this plugin a all-in-one plugin? I don't want to install too many plugins.

AurevoirXavier commented 4 years ago

https://github.com/haskell/vscode-haskell/issues/255

After switch to ormolu, formatter works.

But Evaluate still not working.

lukel97 commented 4 years ago

The evaluate issue is broken on static binaries on Linux, it's tracked by this issue here https://github.com/haskell/haskell-language-server/issues/221