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: