-
Notifications
You must be signed in to change notification settings - Fork 789
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
VS: Make Fantomas auto-discoverable when user invokes F# format document/selection #2693
Comments
Formatting has never been supported. Visual F# Power Tools added it into VS 2012-2015, but we decided not to port it to VS 2017. |
Hi Vasily,
What a pity. Hopefully you all change this idea and put it back as a good facility.
Thank you.
Regards.
From: Vasily Kirichenko [mailto:[email protected]]
Sent: Saturday, March 25, 2017 9:26 AM
To: Microsoft/visualfsharp <[email protected]>
Cc: lasp91 <[email protected]>; State change <[email protected]>
Subject: Re: [Microsoft/visualfsharp] F# format document/selection doesn't work at all with VS2017. (#2693)
Formatting has never been supported. Visual F# Power Tools added it into VS 2012-2015, but we decided not to port it to VS 2017.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub <#2693 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AS4U5Q7dnASA1h-9in2BqM9ji8sE9_QDks5rpCbigaJpZM4MorxY> . <https://github.com/notifications/beacon/AS4U5WiYss_-1j1G0meYpAOr5V278vSxks5rpCbigaJpZM4MorxY.gif>
|
I think this is actually a good candidate to bring over from VFPT. Though not the most critical, formatting is definitely used a lot by people, and many folks do have @vasily-kirichenko Were there some issues in quality? |
The main ccncern was that it did not allow style settings. Another issue is that we used it via fantomas nuget package, which, in turn, depended on FCS package. We cannot use this approach in this repo. |
I have a simple question regarding this limitation... Why is F# different from C# and C++ for example, when dealing with code formating?
Any very/huge specific reason for not behaving like the other languages in .Net or even better, in Visual Studio?
It's really kind of weird for me. Not truly acceptable for a product coming out of Microsoft.
… On 25 March 2017 at 19:39 Vasily Kirichenko ***@***.***> wrote:
The main ccncern was that it did not allow style settings. Another issue is that we used it via fantomas nuget package, which, in turn, depended on FCS package. We cannot use this approach in this repo.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub #2693 (comment) , or mute the thread https://github.com/notifications/unsubscribe-auth/AS4U5dlIrgCqdzKuCpTnvzrZ9E6Z2tmJks5rpLa5gaJpZM4MorxY .
|
The answer is simple as well: limited resources. While Visual F# is a Microsoft product most of the stuff in this area is done by the open source community. There is a lot happening around tooling at the moment and I assume someone will take care of formatting eventually. But right now it seems people's interests/priorities are at other (important) features. TBH there is very little hope that Microsoft will implement formatting, so our best shot is the community. You can be an active part here and help to make it happen. ;-) |
If we port Fantomas sources, it's easy. @dungpa do you mind? |
It seems quite easy to hook "format document" to Roslyn, see http://source.roslyn.io/#Microsoft.CodeAnalysis.EditorFeatures/Implementation/Formatting/FormatCommandHandler.cs,24 |
This is a major issue we are facing with the FCS split, and work to enhance VisualF# Tools; and it is detrimental to the state of all F# tooling outside VisualStudio. Porting over Fantomas code will cause another split in the tooling, require backporting back & forth of enhancements and bugfixes. Same problem appear with FSharpLint, and in fact any F# tooling backed by FCS. The easiest approach, which does not cause those problems, would be to make the packages source compatible with FSharp.Compiler.LanguageService in this repository, and having a bit of fsproj massaging to make it compile easily with either FCS or inplace in this repository, probably a bit of Other approaches involving copying the code only work when the codebase is being deprecated like VFPT. |
We cannot use fantomas nuget anyway, because it depends on fcs, but we don't use the same fcs here and, if even we could, we'd get endless versions collision, like we got in vfpt. |
we'd need to do even more extensive testing of fantomas as it can break code |
@lasp91 Another thing to keep in mind is that a source code formatter is one of the most deceptively difficult programs to write. The space of valid F# constructs and decisions which have to get made by pretty-printing the syntax tree is massive. I think that porting over Fantomas code and modifying it to not depend on the FCS package is a good approach. Not sure about the license. I don't think there's any issue with Apache 2.0. @jongalloway may be able to provide more input here. |
@vasily-kirichenko Feel free to do whatever you want with the code. Just a word of warning, writing a code formatter for F# is significantly harder due to indentation-based syntax. Moreover, the fact that F# ASTs throw away formatting information (e.g. comments) makes the matter even worse. |
@dungpa thanks :) |
I ask that if the Fantomas source code formatter is brought into VS, then make sure it removes spaces at the end of all lines, and not add it to some lines. A code formatter that works against the one most obvious of all de facto formatting rules - remove trailing spaces - I consider not only useless, but a nuisance. Why important? Source is normally written so that there are no trailing spaces in it. A tool that adds trailing spaces will be in constant conflict with developers and other tools. It will cause unneeded source changes, thereby creating a more messy VCS history, sometimes even with commits of files that actually doesn't have any effective changes. Teams waste time counteracting such flaws in tools. |
I just wrote my own source code formatter, may be it can be used for this issue. |
@s-trooper We've used the F# codebase as a test case before, ensuring that CI still passes after a full run. If you'd like, you can submit a PR for personal review to get the project into shape. |
@cartermp i have used CI (jenkins) before but i don't understand what you actually asking for. My project do have some unit tests. But the tests versus F# code i have done manually, by cloning of this repo and run "fsfmt" on it and then build it (successfully). |
Fantomas now provides Fantomas.Client nuget allowing to call into the installed tool out of process, so now we could easily integrate it. |
We'll still need to fork it, if we want it to be part of VS, also, might not play well with live buffers. |
We should make Fantomas-for-VS auto-discoverable, e.g. suggest the marketplace addin by the community when the user invokes F# format-document or format-selection
Old notes:
I can't format any code in F# with VS2017, using the edit/format/advanced/document or selection. This is working perfectly in VS2015.
In VS2015 I had this issue at some stage and if disabling the the "Productive Power Tools", the edit/format started to work normally.
Then, if enabling the "Productive Power Tools" again, the edit/format functionality keept working and I had no issues anymore. All good in VS2015.
In VS2017 I installed the proper "Productive Power Tools", expecting no issues, but noticed the edit/format was not working. I decided to disable this functionality (in Extension and Updates) as I did for VS 2015 to see whether the issue is solved. But it did not solve the problem.
The text was updated successfully, but these errors were encountered: