Migrate to Fantomas.Client about fantomas-for-vs HOT 19 CLOSED

I'm going to deploy the VS2022 version this weekend.
I'm going to spend some time on adding the toast notifications. I'll ship it regardless of whether I succeed or not.

from fantomas-for-vs.

Hi all, we could use some help to implement this.
Time is not our side and I personally lack the knowledge of Visual Studio extensions.
We are looking for a volunteer to finish the port started in https://github.com/fsprojects/fantomas-for-vs/tree/fantomas-client.
If you open that branch, lots of errors should pop up and you would need to replace the existing code with a FantomasService implementation.
Please let us know if you are interested in helping us out.
Any contribution here would be greatly appreciated.

from fantomas-for-vs.

I've been using it for a few days now together with my team, really smooth experience! Being able to now have Fantomas installed as a local tool and it just getting picked up... so good. And finally we can ensure all team members are on the same version 😄

Thanks for the great work to both you Asti, but also to you Florian for Fantomas!

from fantomas-for-vs.

Hey everyone!

I've opened a draft PR to finalize the migration: #25

While it already works for me with VS 2022 17.1.0 Preview 1.1 and fantomas-tool 4.6.0-alpha-008, the latter opens a CLI window the first time I use it. Is there any way to get that window to not be visible? I think this just needs to set CreateNoWindow to false?

from fantomas-for-vs.

Hey Christopher-Marcel! Wow, this is amazing! Many thanks for stepping up here.

I think this just needs to set CreateNoWindow to false?

Yes, we can totally do that and I believe we should have done so in the first place. I'm on it.

from fantomas-for-vs.

I'm tracking all the work in Github projects.
https://github.com/deviousasti/fsharp-formatting-for-vs/projects/1?add_cards_query=is%3Aopen

from fantomas-for-vs.

I'm glad I can finally contribute something back 😄

Please have a look and let me know what you think about these open questions that I now have after testing this a bit more on my end:

1. I removed the options that are for Fantomas (and not for the VS extension). Am I correct to assume that's what we want moving forward, to allow the local/global fantomas-tool to always work with its latest settings, without having to update this extension?
2. I've removed the warm-up logic as it seemed like it was never kicked off (?). However, now that the daemon has to start up first I'm wondering whether the extension should start it in advance?
   1. I've noticed the first format can take around 5 seconds on a beefy rig, which means the user is likely to invoke the formatting a second time... that results in the file having the Fantomas changes (if any) applied twice to the file, giving compile errors and forcing the user to undo, then invoke the formatting once more.
   2. If we were to warm it up I wonder how I could do so as all the FantomasService methods seem to require a file path but the extension doesn't have one.
   3. I'm still unfamiliar with the VS extension APIs, so perhaps there's a better way? Perhaps we could show a modal while Fantomas is running to ensure the user waits for the formatting and does not kick of repeated formatting invocations?
3. If I close the (still visible) daemon window I can currently easily simulate the case of the daemon crashing for whatever reason. The handling of this is currently not great as I just get back errors.
   1. Should I attempt to dispose the previous Service instance and then initialize a new one? How do we ensure we're not trapped in a restart loop with that? Perhaps this should be shown to the user and left up to them to resolve?
   2. Currently, with the state of the PR as is, the user has to restart VS to get out of the broken state and for this VS extension to work again.

I'll be back later again or sometime tomorrow to check for replies, but no pressure! I'm happy to continue on this a bit during the week as well.

from fantomas-for-vs.

I've published 0.3.2.
Some initial responses:

1. Yes, you can fetch the options via the FantomasService. Each version could potential returns different options, so something dynamically will be necessary to deal with this.
2. Warm-up was something specific to this extension. Ionide/VSCode never had this and the first format request will indeed always be somewhat slower than the next ones. I'm open to some ideas here. Perhaps we need to build in the warm-up inside Fantomas.Client.
3. Yes, this is a known limitation for the time being. If you kill a process that you shouldn't bad things will happen.
   We could again handle this a bit better on Fantomas.Client side.

from fantomas-for-vs.

Sorry, I messed up, try 0.3.3 please.

from fantomas-for-vs.

That did the trick to hide the window! Can you also do the same for the tool lookup done by runToolListCmd? That still opens up to three windows it looks like.

1. I'm not sure if it's worth trying to get this into VS. Once you look at whether or not to store the settings via VS' storage and then keep that in a clean state across different versions each project might be using (fantomas-tool installed as a local tool)... it's a bit involved!
   • @deviousasti I can see you've added a task to the project to give great options support for Fantomas in VS. What are your thoughts on keeping it simple and consistent across IDEs/editors and instead ask the user to use .editorconfig to configure Fantomas for their project? I'm not saying nice options integration isn't worth it, I'm just wondering if this is a required part of the shorter-term goal of "just" getting Fantomas.Client used.
2. Thinking about this some more, I am leaning towards ensuring that the interactive scenario in VS (and other IDEs/editors) ensures the user is "blocked" from running another formatting attempt. Since it's a bit involved to ensure there are no two format requests kicked off for a specific range in a document, I think it's best to just outright show a modal or something (with a cancel button of course).
   • That being said... perhaps it's OK to leave this for another time, in case this isn't a big issue for users. If Ionide has been fine this way so far already, maybe it's just a nice-to-have rather than an important requirement?
3. Sounds good! Adding some retry logic (once it becomes a need, that is) to Fantomas.Client is much preferred of course - one solution for all consumers of Fantomas! ❤️

from fantomas-for-vs.

I've updated the PR with the following additional changes:

• Use the latest Fantomas.Client version available now. Still waiting for the change that ensures the last CLI window instances are hidden.
• A progress notification window is shown to the user when the formatting takes longer. Normally the user would only see this once on the first startup as Fantomas.Client has to start the daemon first (but even that is pretty quick, so the window might never show). They can also use the cancel button to cancel the format request.
• In case Fantomas.Client returns an error, the error is now presented to the user in a message box window. Previously the extension printed the error message to the status bar, but that cuts off early for the bigger error messages (e.g. the one you get when #if code paths give issues).

Note: The notification window quickly hides and then shows again because there are still some CLI windows spawned. At least I think so. This should be resolved as soon as Fantomas.Client hides the remaining windows as well 🤞

Here are the VSIX files for both VS 2019 and 2022. I have only tested the latter (and only on 17.1.0 Preview 1.1). Both the local and the global tool install of fantomas-tool work for me without issues.

• FantomasVs-2019.zip
• FantomasVs-2022.zip

from fantomas-for-vs.

This is amazing progress! Tremendous thanks for all of this!
I've published 0.3.4, which should hide the last window.

from fantomas-for-vs.

As for the settings part, I would leave it out for the initial migration and perhaps just put a link to Fantomas online tool.
Users can there change settings and copy their .editorconfig snippet.

From my angle, it would be interesting to get something out there and see how users respond.
We did the same thing with Ionide, we just rolled it out and fixed minor issues as they came in.

from fantomas-for-vs.

I'm onboard with shipping the extension for VS2022 early.
There are not too many users at this point.
I'll use it continuously at work to find out any issues.
VS19 should behave identically.

Some things for a minimum build:

• I'm pretty sure we need to dedupe requests to the server. Is there a standard mechanism.
• How do we plan to deal with the server process crashing?
• How do I cancel an existing formatting request?

from fantomas-for-vs.

How do I cancel an existing formatting request?

All members of FantomasService accept an optional cancellationToken.

How do we plan to deal with the server process crashing?

I saw an opportunity to check on Fantomas.Client side whether the process is still running.
I'll pick this up somewhere this week.

I'm pretty sure we need to dedupe requests to the server. Is there a standard mechanism.

Observables come to mind here, not sure if that would be the best approach.

from fantomas-for-vs.

I've published Fantomas.Client 0.4.0, this one would restart a process when it is no longer running.

from fantomas-for-vs.

Hi @deviousasti and @bddckr, any chance I could persuade one of you to continue the progress here?

from fantomas-for-vs.

Toast notifications?

from fantomas-for-vs.

The migration to Fantomas Client is done. Closing this issue now.
Thank you everyone!

from fantomas-for-vs.