[jwortmann]

Resolves #2706

I haven't tested in practice, but provided that tests are passing, I think it should be working.

Iirc the PHP server wanted to use resource operations, so feel free to test with that (or with another server if you know one that uses resource operations).

Edit: According to sublimelsp/LSP-intelephense#112, testing with the PHP server would require a licensed version of that server. But it looks like there is also a code action in rust-analyzer that wants to use this: sublimelsp/LSP-rust-analyzer#119

[predragnikolic]

There is also a markdown server that supports creating files via a code action #2499 (comment)

I try to test with intelephense(pro) this weekend.

[predragnikolic]

When we create/rename/delete files,
do we need to send the following requests:
workspace/willCreateFiles
workspace/willRenameFiles
workspace/willDeleteFiles

And then notifications:
workspace/didCreateFiles
workspace/didRenameFiles
workspace/didDeleteFiles

[jwortmann]

When we create/rename/delete files, do we need to send the following requests: workspace/willCreateFiles workspace/willRenameFiles workspace/willDeleteFiles

And then notifications: workspace/didCreateFiles workspace/didRenameFiles workspace/didDeleteFiles

I wondered the same, but I would assume that we only need to send these request/notifications if the create/rename/delete is caused by a user action. Otherwise maybe this could even lead to an infinite loop (?)
Because the resource operations were already triggered from a WorkspaceEdit, so I don't think that we would need to do these additional requests, which in turn might result in another WorkspaceEdit.

I think what we need to do in case of a rename resource operation is, that we need to send a didClose with the old URI, and then a didOpen notification with the new URI, for the renamed files that were open in the editor. But I this should happen automatically now, because in 81474da I added that the lsp_uri setting gets updated, which should then trigger a reset of the DocumentSyncListener for that view, and that should automatically send these notifications. But I haven't tested that.

[rchl]

there is also a code action in rust-analyzer that wants to use this: sublimelsp/LSP-rust-analyzer#119

Worked nicely with that use case

[predragnikolic]

Tested with intelephense
✅ Tested successfully ,renaming the symbol will also rename the file as it can be seen in the video

Sublime.Text.mp4

But there seem to be a UI bug lag

Screen.Recording.2026-05-24.at.22.22.30.mov

Pay attention to the blue modified file indicator in the tab

it takes a bit longer to hide... it can be perceived as lagging and there is some UI slight UI flickering

When I rename the symbol:
if I screen record the ST window app:
the blue modified file indicator in the tab is hidden right after the file renamed successfully
else
the blue modified file indicator in the tab stays visible way longer after the file renamed successfully

I do expect the that the blue indicator is hidden right after the file has been rename.

[predragnikolic]

I tested with LSP-marksman as well.

When I click the create file code action,
the fill will be created.
but after we create the file we need to send the workspace/didCreateFiles,
else the server will still show the diagnostic error that the file doesn't exist ("Link to non-existent file"), as it can be seen in the video.

Sublime.Text.mp4

If we send the notification, the server will remove that diagnostic.

(I hit the same error when I playing around with resources operations in https://github.com/sublimelsp/LSP/tree/resource-operations-wip - I will delete this branch, I just pushed the changes so you can take a look)

[jwortmann]

Thanks for testing!

Ok I will add the notifications.

---

Regarding the blue modified file indicator, I assume that is out of our control and depends on ST itself (?)

But I can also not really tell from the video whether you manually save the file after the rename... or otherwise I would expect that the file is still in a modified state after the rename (because the file content on disk was copied into the other file location, but there was no save after the content change), and therefore the blue indicator shouldn't go away. But I might be wrong because I have not tested it.

[predragnikolic]

But I can also not really tell from the video whether you manually save the file after the rename...

I forgot to mention, I am not the one who is pressing save.
The file is saved automatically because I have set:

 "refactoring_auto_save": "always"

[jwortmann]

I forgot to mention, I am not the one who is pressing save.
The file is saved automatically because I have set:

Oh, that makes sense. But yeah, I think this is out of our control and depends on ST (perhaps it takes a bit for ST to react due to the view.retarget that we do when renaming the file).

[predragnikolic]

I will tinker a bit with the code.

I have one assumption now...
UI glitches like this usually happen when code is executed on the async thread.
I will try to move some code to be run on the main thread and see if that would address it.

[netlify]

✅ Deploy Preview for sublime-lsp ready!

Name	Link
🔨 Latest commit	d20b41f
🔍 Latest deploy log	https://app.netlify.com/projects/sublime-lsp/deploys/6a1450e284e8a60008e7d44d
😎 Deploy Preview	https://deploy-preview-2907--sublime-lsp.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[jwortmann]

I have implemented the workspace/didCreateFiles / workspace/didRenameFiles / workspace/didDeleteFiles notifications in d20b41f, and I have successfully tested it with LSP-marksman using your example from above.

Edit: I have not implemented these notifications for the MockManager class from

LSP/tests/test_session.py

Line 30 in 7313cec

class MockManager(Manager):

so I assume they won't be sent during the unit tests.

[jwortmann]

By the way, what happens if someone has also installed LSP-file-watcher-chokidar - will there be additional notifications triggered by that when a file in the workspace gets created or deleted?

Edit: I guess I can answer myself; according to the readme https://github.com/sublimelsp/LSP-file-watcher-chokidar#usage the file watcher seems only be relevant for workspace/didChangeWatchedFiles notifications. So it should be fine and there should not be any duplicate notifications.

Edit 2: The description in the specs at https://microsoft.github.io/language-server-protocol/specifications/lsp/3.18/specification/#workspace_didChangeWatchedFiles for workspace/didChangeWatchedFiles reads like this notification is a replacement for the individual didCreateFiles / didRenameFiles / didDeleteFiles notifications (?). Although that is not explicitly mentioned, and I wonder why the description is so vague about that. But I guess having support for all those notification types in LSP is fine.

[jwortmann]

I will tinker a bit with the code.

I have one assumption now... UI glitches like this usually happen when code is executed on the async thread. I will try to move some code to be run on the main thread and see if that would address it.

Do you still want to test this, or should we merge this PR and if we find some improvements we can do that later?

[predragnikolic]

or should we merge this PR and if we find some improvements we can do that later?

Merge would be fine. I will try to revisit the issue that I reported, once I dedicate more time to LSP.

Janos, can you just confirm that this part of the spec is present in the PR - "execute the operations in the order in which they are provided"

Since version 3.13.0 a workspace edit can contain resource operations (create, delete or rename files and folders) as well. If resource operations are present clients need to execute the operations in the order in which they are provided. So a workspace edit for example can consist of the following two changes: (1) create file a.txt and (2) a text document edit which insert text into file a.txt. An invalid sequence (e.g. (1) delete file a.txt and (2) insert text into file a.txt) will cause failure of the operation. How the client recovers from the failure is described by the client capability: workspace.workspaceEdit.failureHandling

[jwortmann]

Janos, can you just confirm that this part of the spec is present in the PR - "execute the operations in the order in which they are provided"

Yes, we should handle it correctly with this implementation. This is the why it is implemented as such an ugly recursive function, because we need to chain the next Promise after each operation (or stop as soon as there is a failure).

[huyby]

Thanks, works like a charm using lsp intelephense ❤️