Enable `forc fmt` to operate on the LSP tmp files so it can format unsaved changes.

[JoshuaBatty]

There has been a few reports on Slack where people are running into problems with the lsp_lock files disabling the ability to run forc fmt

from Cam

I'm still getting this error every once in a while. The solution has been to delete .forc/.lsp-locks/. I think it has to do with the fact that I have multiple instances of VSCode open across multiple repos i.e. sway, sway-standards, sway-libs, my test projects, etc. I haven't found a consistent way to reproduce it.

from Swayam

I only have one vscode open so I don't think there being multiple is the problem

If we just consider the following scenario. A user is editing a file in vscode with unsaved changes. They then run forc fmt in the in built terminal. This will produce the error above. This is because forc fmt is only operating from the saved file on disk which contains the unsaved changes.

One idea is instead of just locking this operation, we could use the file saved in .forc/.lsp-locks/ to contain the path to the file in tmp. This way, forc fmt could then get access to the unsaved changes and still run formatting on the file that lsp is operating on. This would remove the need for locking the forc fmt process.

[JoshuaBatty]

Just leaving a note for myself to also handle how the new forc-migrate tool uses the lock file #6790

[JoshuaBatty]

So I tried the above and it doesn't work as expected as the unsaved changes in the editor are stored in memory, so saving the tmp file doesn't actually propagate those changes into the editor.

Taking a look again at rust, if there are unsaved changes in the editor and cargo fmt is ran, then the formatter executes but does not format that code as it is operating on the saved version on disk. This is the same behaviour that we are currently doing, although we actually tell the user why formatting was not applied and tell them to save the file.

@SwayStar123 @bitzoic So for this to work the user needs to save the file before running the formatter. Feel free to let me know if you think the UX for this process should be improved or changed.

[SwayStar123]

So I tried the above and it doesn't work as expected as the unsaved changes in the editor are stored in memory, so saving the tmp file doesn't actually propagate those changes into the editor.

Taking a look again at rust, if there are unsaved changes in the editor and cargo fmt is ran, then the formatter executes but does not format that code as it is operating on the saved version on disk. This is the same behaviour that we are currently doing, although we actually tell the user why formatting was not applied and tell them to save the file.

@SwayStar123 @bitzoic So for this to work the user needs to save the file before running the formatter. Feel free to let me know if you think the UX for this process should be improved or changed.

I have auto save on for every 0.1 seconds, and I also manually save with ctrl+s every time I see this error, doesn't do anything.

[JoshuaBatty]

Can you make a screen recording for me?

[SwayStar123]

Can you make a screen recording for me?

When i encounter it the next time, sure.