Discussion: implement line separator service

[vasily-kirichenko]

I found this feature (turned off by default) in C# editor:

I'm not sure it's worth implementing though. Ideas?

[cartermp]

I think that if it were to be implemented, it would likely be low priority. I think it has less benefit to F# than to C#/VB (turned on by default in VB, actually) because F# is a lot less verbose, but I could see someone liking it. I certainly wouldn't vote to reject a PR that implemented it.

[vasily-kirichenko]

I think there should be a setting to turn it off, which faces us with the old problem: we don't have a good settings dialog page.

[cartermp]

Yeah, true. In that case I think holding off on something like this is appropriate for now. Once we have a good settings dialog with some ability to configure and tweak IDE features, this seems like something worth implementing.

[vasily-kirichenko]

👍

As usual, I think we should steal the dialog from C# editor (not its content as is, but the way it works and the design).

[cartermp]

Agreed!

[forki]

I think the dialog is high priority. I'm already confused by all this aggressive code folding and block structure noise. It's really scary how much noise C#ers use. @vasily-kirichenko please steal the dialog and then we should discuss which things are really worth to be turned on by default

[forki]

Just for the record: I'm not saying these things are not awesome new features. It's just that I think we should be really conservative with turning these on by default. 4 spaces indent is usually already a great visualization.

[vasily-kirichenko]

Unfortunately, as VisualFSharpOpenSource.vsix does not work for VFT solution, I don't use current muster at all and I don't have any opinions on what features should be turn on by default.

However, turning off features by default is somewhat dangerous because the vast majority of users never go to settings to examine what's available. That's the case with coloring in VFPT - I very rarely see that people use any colorization except the default one (types only), which is unfortunate.

So I think all the features should be turned on by default. Maybe we should provide "tips" via that new annoying yellow bar, like "Do you know that you can turn off the block structure helper in settings?". What's nice about this approach that people will find the way to turn off annoying features.

[forki]

Yeah that is a tough decision. I don't claim I have the perfect answer.

[cartermp]

@forki I think the dialog isn't quite high priority (although I'd say it's a higher priority than this specific feature). One of the awesome things about VS 2017 from an infrastructure standpoint is that the internal changes were made to allow for a much more rapid cadence for releases, allowing us to gradually move away from gigantic updates that change hundreds of things and potentially break people, and move more towards smaller updates that are more focused in certain areas. They also don't have to be monolithic anymore - one Workload may be completely unaffected by an update to tools in another Workload, for example. What that means is we're free to iterate a bit more rapidly (or slowly) and not be burdened with getting bundled up with a lot of unrelated stuff.

I think that because there's a lot of attention from the community on getting features from VFPT and trying to achieve "experience parity" with C#/VB (where it makes sense), I think it's best to focus on getting as many features in there that we can - provided that they're tested and aren't totally broken, of course.

If a dialog could get made that's simply some checkboxes, like VFPT, and done so in a week or two, I'd be ecstatic to have it in. But I agree with @vasily-kirichenko that we should default to these new features being on, with the only exception being if a particular feature is really bad performance-wise compared to the rest. Put another way, I'd much rather people complain about there being too many IDE features for F# than too little, and dial features back based on feedback if necessary.

[forki]

1. I think there must be a way to disable features. There is no way around this since features can always be buggy in certain scenarios and we must give people a way out. Otherwise it will be a nightmare. (it can be manually editing regedit or worse but there has to be a way out)
2. some IDE features from C# just don't make any sense. We need to be careful

[cartermp]

I can't think of many features that C#/VB have which don't make sense for F#, excluding language feature Analyzers (like suggesting the new is pattern over var y = x as T; if (x != null)). Certainly any feature that makes working with .NET libraries and various .NET-isms easier we'll want to bring forward, and things like completion without having to hit ctrl-space are also great.

But I completely agree that we need to have a way to toggle things off and on, and moving forward, a way to tune them (like if we implemented predictive completions, being able to dial how "smart" it tries to be).

I think that block structuring is one of the more controversial features since it does add more noise to the IDE. If we can hammer out a few more bugs in it, then I think we'll be able to evaluate if on or off by default is the best. Right now, there are enough bugs there where I think turning off the feature until they're fixed is the right move.

So to summarize my view:

If the quality isn't high enough, it should be off by default. If the quality is there, it should be on by default for this release, but we can absolutely have a discussion about it. And each feature should be toggle-able.

Where this gets tricky is the RTM release of VS 2017. We only have a few short weeks before we're in a code freeze, and if we can't get a settings dialog in on time, I'm much happier with there being too many features than too little features.

[dsyme]

I'm much happier with there being too many features [on by default] than too little features.

But only if they are all of sufficiently high quality!

[dungpa]

My worry is that we now have very little control on toggle features on/off since all service initialization is done in Roslyn. For example, for #1800, we even need some code change in Roslyn.

@Pilchie @CyrusNajmabadi Could you give some pointers on how Roslyn handle feature toggling via Text Editor options? Thanks.

[Pilchie]

@dungpa - we map text editor options to Roslyn options here