Ionide-vscode-fsharp: new fsi window works much badly than previous

[flypixel]

Hello, I've just updated to last version (2.5.0) and it seems to me like it is a step back. With new fsi I can't clean screen any more, I can't scroll a window of fsi, also it's not working when I send #I directive to fsi, it says that the directory can't be found, but in a previous version it could (may be because it runs in a project directory, but not in a directory, where the file lays).
VS Code 1.5
Ionide-vscode-fsharp 2.5.0
Ubuntu 16.04

[rmunn]

I downvoted because I disagree that it feels like a step back. With FSI in the Terminal window, it finally allows me to type directly into FSI for things like test data that shouldn't be in my source code, and then once I get the test working I can copy the appropriate statements into my unit tests.

But I do agree that the #I directive problem is annoying. It's a breaking change to .fsx scripts, and it would have been nice to have clearer documentation of what directory relative paths should be interpreted from. I do think that it makes more sense to have relative paths start from the project directory rather then the directory the file is in, since that removes the annoying "../../../../" sequence that I was always getting wrong. (And the project directory won't change when you move a file to a different directory, which is another nice bonus). But it might be nice to have some sort of note in the release notes that the semantics of #I and related directives has essentially been changed in 2.5.0.

UPDATE: I've retracted my downvote because despite some major improvements to the FSI-in-Terminal experience, I still prefer the old FSI output window. I'd like to see that brought back as a configurable option: either use the Terminal or a VS Code output pane, depending on what the user selected.

[flypixel]

Sorry, but it doesn't make sense to have relative paths start from project directory, because for fsi it self it works in another way and all other tools works in another way, and the workspace directory can be changed, and I think it shouldn't affect on references. And really I almost never want to do some change in fsi directly, but of course it's good feature, but not very important.
The real cool feature would be autocomplete in #r and #I, like in emacs. Thanks

[kirill-gerasimenko]

@rmunn I would disagree with the "project directory" part. It is expected that relative paths are relative to the current script file.
I can confirm that now #load directive is not working properly - it can't find the file using relative paths. I think it's due to the way FSI is started right now. I've got D:\ as a path for my powershell config, and error messages says that it can't find file from #load directive in D:\ location.

[rojepp]

@flypixel You can have #r and #I completion right now by installing the extension 'Path Intellisense'

[flypixel]

@rojepp thanks a lot

[Krzysztof-Cieslak]

• Relative paths are fixed in 2.5.1
• You can scroll fsi window using mouse wheel / touchpad... not sure why there is no scroll in the UI or how to scroll it with keyboard, but I guess that's an issue for Code repository
• I don't think there was an option to "clear screen" in previous version.

[flypixel]

I don't think there was an option to "clear screen" in previous version.

Yes, there was. It was called clear output and you could do that by the context menu or the button in the write corner of window. It was very helpful:).

You can scroll fsi window using mouse wheel / touchpad... not sure why there is no scroll in the UI or how to scroll it with keyboard, but I guess that's an issue for Code repository

Sorry, but I can't scroll even with mouse wheel. Maybe problem with me :), but in previous version I could. And it's not a problem of vs code, because in integrated terminal everything works correct: there is scroll in UI and it's scrolled by mouse wheel correctly.
Sorry, but it looks like you don't use tools that you participate in, you should try, it is not so bad :)

[slang25]

The new fsi implementation is a great improvement, and scrolling is working on my machine. Thanks for your work @Krzysztof-Cieslak!

VS Code 1.5
Ionide-vscode-fsharp 2.5.1
Windows 10

[kirill-gerasimenko]

In 2.5.1 the fix works, but when the FSI process is started, it gives error, if you Alt+Enter second time - selected text is executed fine. I haven't gone to the details of new FSI implementation yet, but at first glance it looks like silentcd is executed in the wrong sequence (after the evaluated text, not before).

On the picture you can see me selecting #r two times in a row, first one give error, second works fine.

Also I've noticed that if you delete terminal using standard way (trash icon on terminals tool bar) - it's terminated fine, but Alt+Enter doesn't work anymore, though it should start new FSI instance.

I can take a look at that today-tomorrow if it's not critical.

[Krzysztof-Cieslak]

@kirill-gerasimenko:
I (hopefully) fixed startup behavior in 2.5.2. Please create separate issue if it's still not working for you.

Unfortunately currently there is no API to detect if Terminal was manually closed, so nothing we can do about it.

[flypixel]

@Krzysztof-Cieslak sorry, that maybe I was rude. You've done a great job, thanks.

[kirill-gerasimenko]

@Krzysztof-Cieslak, unfortunately it didn't help :(

The increased timeout for silentCd didn't help and I was able to get why - I've got powershell as a terminal, and with my custom profile it takes ~4-6 seconds to just load. So 1.5 seconds is not enough. I've tried CMD version of terminal and it worked fine.
I'll create a separate issue as you suggested.

Regarding the Terminal API in VsCode - yeah, they don't give anything related to spawned process outside of ITerminalServices implementations :(
The only available thing is processId as far as I understood, when you call createTerminal. Can it be used? Say when you first create terminal you save processId and when user Alt+Enter (or any other FSI related commands) again - check if process with this id exists than send text to terminal for evaluation as usual, if the process id is not there - than start new terminal, rinse and repeat :) Of course there is a possibility that process with this id will be killed externally and another one will use the same id, but it can be a good temporarily trade-off. At the moment the only way I managed to workaround it is using "Reload window".

Please let me know what you think.