Add line inforamtion for fsi

[psiLearn]

With an additional
#line Selection.linePosition - 1
the error information in the fsi would be better readable.
see: compiler-directives

[cloudRoutine]

I'm not exactly clear on what you're asking for, could you provide some more detail or an example of what the desired output would look like? I think I know what you want but I don't think appending #line to all of the lines in the selection will produce the result you're looking for.

[psiLearn]

If I send let foo = 1+2.0 to fsi from vscode I get Advent20161105.fsx(2,13): error FS0001: The type 'float' does not match the type 'int' and if I send it again I get Advent20161105.fsx(4,13): error FS0001: The type 'float' does not match the type 'int'. So the line numbers are increasing as I send it over and over again to fsi.
If #line 0 in this example would be added before the Code, like \n;; is added after the Code, the error would be Advent20161105.fsx(1,13): error FS0001: The type 'float' does not match the type 'int' and give the right line number.
So this is what I suggest to send to the fsi:
#line 0\n let foo = 1+2.0\n ;;

[Krzysztof-Cieslak]

We won't go with. Since moving FSI to terminal integration we don't have any way to filter / control what's displayed in terminal. This means that any additional directive is adding lot of noise to output displayed in terminal (what's clearly visible in case of other directives we're automatically adding).

Thanks for suggestion anyway! :-)

[Tyriar]

@Krzysztof-Cieslak what's the issue here exactly? It's not clear from your (very old) comment.

[Krzysztof-Cieslak]

@Tyriar,
We’re currently using Terminal API for our F# Interactive (REPL) integration - we create new Terminal with fsi.exe as running process. This allows us to create typical REPL experience - users can type code into REPL (terminal) and on top of that we have commands like Send Selection/Line which writes code into Terminal using API.

F# interactive supports set of directives that can be sent to it to improve error reporting, especially in editor context - such as # FIlE_PATH (to notify interactive in which script file we currently are) or # LINE COLUMN (to notify position in the file), or #line LINE (to notify current line)

We currently do that only partially - sending # PATH when we change file, but we don’t send other directives at all - it would mean we need to send position or line directive on every cursor movement. Sending those directions so often would create huge amount of text being print out into Terminal and that’s not what we want neither - it’s just noise, we want to have users code and results of the execution visible.

What we’d need here is an API that would write text to Terminal process but this text wouldn’t be displayed in Terminal panel. I think we’ve discussed it on some other issue already and conclusion was that this is not really possible with current terminal architect (at least back when I asked similar question)

[Krzysztof-Cieslak]

@Tyriar, also to be clear - this is small quality-of-life thing, I don’t believe it is a huge problem for Ionide users. There is always someone who will complain about some small thing as if it was the “sever issue” that makes thing unusable

[reinux]

@Krzysztof-Cieslak I have to strongly disagree that this isn't a severe issue. Not being able to see the line number in the stack trace makes debugging exceptions a nightmare. That would already be true working in a fully built program, and it's doubly complicated in REPL, since you aren't typically working with debugger already attached.

[Tyriar]

What we’d need here is an API that would write text to Terminal process but this text wouldn’t be displayed in Terminal panel. I think we’ve discussed it on some other issue already and conclusion was that this is not really possible with current terminal architect (at least back when I asked similar question)

@Krzysztof-Cieslak yeah I don't think this is possible by design of how terminals work in general isn't it? When you run Terminal.sendText we don't write that to the terminal, well give that to the process and it decides whether it wants to echo that onto the terminal or not.

As an aside, I'm currently working through an issue that would let you take much more control over this sort of thing by having the extension own the process (microsoft/vscode#70978, we're still figuring out exact naming and it's proposed atm). You would need to handle a lot more yourself if you did this though as you would own creating the process/pty (node-pty is not stable vscode API), but then they're your pipes to do with as you wish if you want to suppress output. This is the mechanism that live share uses to do terminal multiplexing (technically they're still on the previous terminal renderer proposal which is now deprecated in favor of virtual processes).