Should VFSI support intellisense

Coordinator
Jul 11, 2014 at 1:29 AM
Edited Jul 11, 2014 at 1:31 AM
Over in the fsharp data science group there is a very active discussion about whether FSI or VFSI should have intelli-sense. It has morphed somewhat into a discussion about repl's in general. But hey! that's what the inter-webs are for.

https://snt148.mail.live.com/default.aspx?fid=flinbox#tid=cm4pfoNoUI5BGhcwAjfeRhHA2&fv=1&fid=flMaFCGQ_kikOC192rHI7aMA2

I think it would be useful for us to have a discussion about intelli-sense and VFSI. Lets face it, FSI doesn't even have syntax coloring, while I'm thinking about it, it doesn't have code formatting either, oh and a depth colorizer would be usefull too. Hmmm how about implement interface.

In one view of the world it's crazy that we have an editor, with all of these features and yet VFSI is little more than a wrapper around a console app.

What about debugging? should VFSI support that? I can't imagine why you wouldn't want it to ... it makes sense after all.

Then there is replay commands on reset that's good right?

How about a watch window, where I can see the state and perhaps modify it of the current FSI session?

How about intelli-sense into object state, I.e can I use intellisense to list the fields and values of those fields?

What about being able to launch an FSI window that is embedded in VS, and then drawing on it, graphs, pictures, forms, grids!!!!

These are all suggestions that have cropped up internally, but we have never had the time to get to. Now that we are open source let's figure out which ones we can do together as a community.

How do we as a team (that includes the entire fsharp open source community) figure out what to do to make FSI and VFSI a world class tool for doing this kind of stuff. Here on the Microsoft Visual F# team we are eager to help make each of these a reality, but we need help from you to achieve that. What features do you want to make happen, in which order and which ones will you help to achieve?

Kevin Ransom
Jul 11, 2014 at 7:31 AM
Edited Jul 11, 2014 at 7:33 AM
I really don't care much about improving the direct text input of FSI. There are other things I do every day that are painfully slow and I'm much more likely to pop up a new script file and use that instead of fsi directly in any case.

I'd much rather have better visual studio integration. I'd like it if FSI somehow could easily load up the project I'm currently working on, or at least one-click reference the dll (without the file write lock please!). I'd also like it if there was a run-in-fsi test option with the debugger automatically hooked up, even just having a one click hook-to-debugger option would be great.

Following the lead on several current community projects, I'd like it if there were a #N command for pulling in nuget packages. Bonus points if you can set it up to automatically put it in the project references.

Another great thing to have would be an integrated F# unicode rewrite support that makes the operators look nice. Haskell currently has something like this and it's beautiful: http://www.haskell.org/haskellwiki/Unicode-symbols
Coordinator
Jul 11, 2014 at 8:15 PM
Edited Jul 11, 2014 at 9:53 PM
I agree, nuget support in FSI is another excellent idea that is often requested, I'm also pretty sure it's not that hard to do, it just needs doing. I would love to see a community proposal for it. I may take a look at it myself, when some of my backlog shrinks, but right now I have a ton on my plate.
Jul 12, 2014 at 12:12 AM
I think syntax highlight and intellisense would be awesome. I played a bit with the Roslyn repl and it's a huge improvement on usage experience.
Jul 14, 2014 at 10:07 AM
I dont think tooltips or completion is needed.

The intent is to write the code in the IDE where you have all these rich features, and send parts of it it to the interactive window for evaluation, it should be read only really.
Jul 14, 2014 at 11:33 PM
An option to disable string and list truncation would be great.

I like to use the REPL as a tool for exploration and experimentation and I think syntax highlighting, code completion, and intellisense would facilitate those ends. The lack of these features has led me to use Sublime Text to experiment using the F# REPL more than Visual Studio.
Jul 15, 2014 at 5:47 AM
I'm afraid it's impossible to disable the collection truncation because the algorithm that does it is not tail recursive.
Coordinator
Jul 17, 2014 at 11:38 PM
My thoughts on some of these...

Intellisense + goodies in FSI
In terms of direct code entry, the FSI window today is more or less useless for anything except simple one-liners. Non-trivial code development occurs in the editor, which supports all the bells and whistles, then you send relevant snippets to FSI purely for execution purposes. This is the same model as the Powershell ISE, the MATLAB editor + terminal, and the RStudio editor + terminal, and probably more. This model works pretty well for what it does.

If we wanted to support real code development in FSI itself, there are more immediate needs than syntax highlighting and intellisense, IMO. The existing hosted experience lacks even the most primitive of text editing capabilities. You can't modify anything but the last line of code. Arrow keys do funky stuff more akin to behavior in cmd.exe than expected cursor-control. You can't do find+replace. etc

Rather than trying to make FSI more editor-like, it might be more fruitful to explore the option of making the editor more FSI-like, with the existing rich editing experience plus inline execution results. Something similar to iPython Notebook or Mathematica.

Debugging
I would love to see a better script debugging experience. As Rick points out, you can attach VS to the fsi.exe process and debug you scripts that way, but this is rather cumbersome and I don't think it dawns on many people to try this. It's also rather fragile - if you move code around in your script after it's been sent to FSI, the debug info in the generated assembly no longer matches the code, so you can't set breakpoints or step through code properly. That being said, it does work...

We could at least make attaching easier/more obvious. What if we automatically attached to FSI when you send a snippet? Perhaps add a dedicated command "Send to FSI with debugging" which automatically attaches to the hosted FSI before sending the snippet. Or even simpler, just a context menu item "Attach debugger to FSI process"?

Watch window
This could be cool. MATLAB, RStudio, others have something like that built in. I haven't used it myself, but I think FSEye fills that gap pretty well. I wonder what the current status/limitation of that project are.

Profile/Startup Script
I'd personally love to have support for a configurable FSI profile or startup script. Both global-per-user and per-project. This would provide a simple hook that allows for the definition of helper functions or library extensions, #r references to commonly-used libraries, re-generation of test data, custom printers, etc, without needing to explicitly do a "send to FSI" action every time you restarted the session.
Jul 18, 2014 at 2:52 AM
You had me at "making the editor more FSI-like." Yes, please! In general, I like a lot of your points, Lincoln. If I may throw out one more idea, it would be to compile the current build configuration each and every time a file is saved while still leaving the editor window responsive. Mighty Moose did a good job of this in the past.
Jul 19, 2014 at 12:38 AM
There's already a cool watch window thing called fseye. Check it out: https://code.google.com/p/fseye/

Of course it would be ideal to have something nice like that right in Visual Studio.

Richard Minerich
Microsoft MVP (F#)
@Rickasaurus
[email removed]
phone: 860-922-3456


Jul 24, 2014 at 4:07 AM
I had another idea to add to the list:

When debugging an application, when I've run across bugs and such in the code, what I've really wanted to do, was grab that object and play with it like it was in a repl. Something similar to the immediate window except with a real code editor attached and preferably not attached to process from which it came (so I can stop debugging).

To be more direct, I want the ability to pull an object out of a running application and send its type information and the particular instance I've selected, to the repl.