Add intellisense to VS FSI

[vasily-kirichenko]

It would be great to have intellisense in VS FSI. There's an add-in https://marketplace.visualstudio.com/items?itemName=AlekseyVlasenko.FInteractiveIntellisense which does it in, AFAIK, in a hacky way. We could port it and make it right way.

[Pilchie]

The "right" thing to do here is use the interactive window component built for Roslyn that Python Tools are now using too.

It separates input and output into different ITextBuffers and constructs a view over an IProjectionBuffer.

[vasily-kirichenko]

Hm. I've played with C# REPL a bit and I don't find it superior to F#'s. I'm not sure it's "the right thing" to do to rewrite the REPL on top of Roslyn REPL shared code. I'd like to just add colors and autocomplete to the current interactive window.

[Pilchie]

Well, it's just difficult to build a classifier plus completion system that works on a single buffer that is a mix of input and output.

The InteractiveWindow component just makes it easier to separate the different parts so they can each be handled independently.

Speaking as someone who hasn't used either REPL much - what don't you like about the C# one?

[dsyme]

FWIW, my position has always been that the FSI window should be output-only (with better visualization of the active state of the session), and we should only support the send-to-interactive-from-script as input. (Perhaps we could support a separate "scratch pad" input window). In this model no intellisense is needed in the output window, though better data visualization is

This is a controversial position and I never saw it through, but I think it's a more coherent position than embedding a terminal console. It aligns with many interactive programming system. For example,

• T-SQL evaluation supports output only (why would you ever mash the query being edited into the same screen area as the output table?).
• The Notebook model cleanly separates output cells and input cells. In F# scripting, separating input and output encourages document-oriented programming (the focus is on the script not the console)
• The F# Interactive in Try F# never supported editing in the output window and no one really complained
• It allows for better investment in visualization apparatus, value inspection, tables, images, charts etc. in the output window. This stuff is much harder to implement in windows also supporting input
• It leads to awkward problems with multi-line editing

To me, it's just a historical quirk that we somehow expect FSI in VS to look like a console, stemming back to when LISP was originally developed on 1960s consoles Mixing input/output in one window is fine for fsi.exe as a command-line tool, but I don't think it's particularly right or necessary or even well-thought-out when hosting interactive execution in Visual Studio.

[vasily-kirichenko]

Speaking as someone who hasn't used either REPL much - what don't you like about the C# one?

I don't like how the caret moves anywhere, e.g. it's not constrained by the current line. Also I don't like the key binding where Up and Down do not scroll commands history, but move the caret up and down, which has zero usefulness for F#.

[Pilchie]

Got it. Both of those should be tuneable per langauage - and the second is a consequence of the first :). Alt+Up/Down do work for history navigation, and the C# REPL tries to support single line input if it detects a complete entry, but that is heuristic based.

[Rickasaurus]

I rather like being able to inspect variables interactively in FSI. This is functionality I use regularly. It would be pretty annoying to have to put your inspection logic inline in your active code base where you might forget to remove it later.

I would be fine with a "scratch pad" but currently no such solution exists.

[slang25]

@dsyme I feel underqualified chiming in, but I don't think what is being proposed violates your concerns. I would love an FSI that looks and behaves a bit like the Chrome dev tools console pane i.e. Up/Down for previous/next command history, completion, and all of the formatting that FSInteractiveServices gives you.

It does overlap slightly with scratchpad/workbook/notebook style solutions, but does that cause harm? I agree that there should be no mix of input/output buffer and no multiline.

[Rickasaurus]

One nice feature of intellisense in FSI is that it could be done in context of what you've already sent to it instead of what's in the file, which can be a headache.

[xperiandri]

@Rickasaurus, is it related to Roslyn REPL? @Pilchie, let's clarify for every one: Roslyn REPL can be populated from current selection as well as from whole project and work not only in the way it works with C# but be tuned for F# Interactive like behavior. And its usage must be simpler than adding tons of missing features to current F# interactive. Is it correct?

[KevinRansom]

In this instance, I am actually with Don ...

My work flow involving FSI always involves typing into a .FSX file, and using the intellisense and coloring in that window. As soon as I type directly into FSI the mix of source-text and program output and the difficulty of discerning which is which and the required indenting always gets me running for VS and creating a new .fsx so that I can separate the output from the F# source text.

I can see why folks want these features in their REPL but for any work other than a few brief lines I find it virtually unusable. Whereas the current workflow of editing in .fsx file and sending the result to fsi works really well.

If I had a hundred bucks to spend on improving fsi ... I would spend it on that experience.

For example ...

• Reducing the need to send to fsi ...
• Tooltips showing the fsi values of variables
• Debugger breakpoints, watchpoints without a debugger mode
• Tooltips showing the input and output of |> and <|
• Support for a history and reset to current point.
• Pushing the current state of FSI trying something and reverting to the previous state.
• Full screen always live scripts (edit the script and see the results in the output windows)
• Scripts that support integration of live code and markup
• Support for alternat output windows, the ability to create graph and table windows from FSI easily.

I could in-fact go on for ever .... to sum up ... I don't really mind if FSI is enhanced to support intellisense, coloring and the like ... however ... I don't think it will really improve the utility of the tool ... it may make it easier to learn and will certainly make demonstration's look cooler. But I suspect it will not significantly improve the functionality of it.

[jackfoxy]

Sometimes I do find myself doing quick and dirty little prototypes in the FSI window, and the add-in mentioned at the top comes in handy for that. I wouldn't want support built out beyond what is available with it.

[slang25]

I think I see what you are getting at. It's the difference between Powershell ISE (with the split document and REPL view) and Swift Playground, if you get it right the latter is a much better experience (and cool, that's gotta count for something?). Play to the strengths of each view.

Example:

[KevinRansom]

This is how I Roll ....

[cartermp]

I agree with @Rickasaurus here:

I rather like being able to inspect variables interactively in FSI. This is functionality I use regularly. It would be pretty annoying to have to put your inspection logic inline in your active code base where you might forget to remove it later.

I find myself doing this a lot and find it more natural than using FSI as output-only.

[rojepp]

I agree with @cartermp and @Rickasaurus, I'll typically write one-liners to test my script file functions directly in FSI to avoid polluting my script. I've never typed more than one line into FSI on purpose, so...

How about having a single input line at the bottom of the FSI tool window?

• The input would get focused when the tool window gets focus
• Can still select/copy text from the output buffer
• Intellisense could be applied in the input line only.
• Input and output could be coloured separately.
• No need to type ;;, just enter.
• Won't forget to remove throw-away code from script file
• Implementation in FSI tool window would be simplified

[isaacabraham]

@rojepp I'm not a fan of entering into FSI but a single kind entry like you suggest - with autocomplete - would be very nice and I think would be a nice solution.

[cartermp]

Another angle to consider is that active use of the REPL is common in other functional languages that we may wish to attract people from. Being able to say, "We have tooling that takes your REPL experience and makes it even better with IntelliSense" is a pretty great value proposition.

[KevinRansom]

Actually … that seems like the best argument in favor of doing it … and why I say I don’t mind it … it just won’t improve functionality.

I have to admit this PR : “Add colors to FSI output” : https://github.com/Microsoft/visualfsharp/pull/2156 got me quite excited.

Because I use FSI, I would love for us to improve the FSI experience for those who use it on a daily basis, but I suppose there is a “glamour improvements” angle and some repl-envy to deal with. Kevin

From: Phillip Carter [mailto:notifications@github.com] Sent: Wednesday, January 4, 2017 3:07 PM To: Microsoft/visualfsharp visualfsharp@noreply.github.com Cc: Kevin Ransom Kevin.Ransom@microsoft.com; Comment comment@noreply.github.com Subject: Re: [Microsoft/visualfsharp] Add intellisense to VS FSI (#2161)

Another angle to consider is that active use of the REPL is common in other functional languages that we may wish to attract people from. Being able to say, "We have tooling that takes your REPL experience and makes it even better with IntelliSense" is a pretty great value proposition.

[dsyme]

Reopening as this is the canonical issue for this feature request right now

[xperiandri]

This must happen as a side effect of migrating to modern C#/Python like REPL tool window

[cartermp]

There are several options to do this, the most immediately doable is to depend on InteractiveWorkspace (requires a new shim in Roslyn to expose to F#) and plug in the completion provider. It's not trivial work by any means, but this would unlock a more modern VFSI tool window with some new features.

Unfortunately, there's also a long tail of work to identify everything the current window does and port over functionality so that there's little or no diff. In total, this is a pretty big task.