Skip to content
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

No activations event for file events #86063

Closed
dbaeumer opened this issue Dec 3, 2019 · 12 comments
Closed

No activations event for file events #86063

dbaeumer opened this issue Dec 3, 2019 · 12 comments
Assignees
Labels
api feature-request Request for new features or functionality file-io File I/O
Milestone

Comments

@dbaeumer
Copy link
Member

dbaeumer commented Dec 3, 2019

Testing #85929

We should have activation events for the provided file events (e.g. onWillRename, ...)

@dbaeumer dbaeumer added the api label Dec 3, 2019
@jrieken jrieken added the file-io File I/O label Dec 3, 2019
@jrieken jrieken added the feature-request Request for new features or functionality label Dec 3, 2019
@jrieken
Copy link
Member

jrieken commented Dec 3, 2019

This needs to go into the textfileservice and(or?) the working copy service

@bpasero bpasero added this to the Backlog milestone Dec 5, 2019
@bpasero
Copy link
Member

bpasero commented Dec 5, 2019

To clarify: is this about allowing an extension to get activated on the new text file events introduced? Similar to how we activate file system providers for example?

@dbaeumer
Copy link
Member Author

dbaeumer commented Dec 5, 2019

Yes.

@bpasero
Copy link
Member

bpasero commented Nov 3, 2020

@dbaeumer any thoughts on the naming for such an activation? I assume you would want just one activation for any file operation and not one per kind right?

@jrieken

This needs to go into the textfileservice and(or?) the working copy service

Isn't this the right place? Right before we call $onWillRunFileOperation:

return proxy.$onWillRunFileOperation(operation, files, timeout, token);

@dbaeumer
Copy link
Member Author

dbaeumer commented Nov 3, 2020

To ensure that it is not mistaken with file events one idea would be onFileOperation

@bpasero
Copy link
Member

bpasero commented Nov 3, 2020

@dbaeumer so onFileOperation would be the activation event when:

  • onWillCreateFiles
  • onWillDeleteFiles
  • onWillRenameFiles

Fires?

@dbaeumer
Copy link
Member Author

dbaeumer commented Nov 3, 2020

Yes, I think one is enough. We don't need to distinguish between create, rename and delete.

@jrieken
Copy link
Member

jrieken commented Nov 3, 2020

Wouldn't the existing onFileScheme:<scheme> be enough? It fires whenever an file is read or written

@bpasero
Copy link
Member

bpasero commented Nov 3, 2020

Looks like we don't need this.

image

@bpasero bpasero closed this as completed Nov 3, 2020
@dbaeumer
Copy link
Member Author

dbaeumer commented Nov 4, 2020

@bpasero just checking: wouldn't you need to trigger the activation. I assume a delete does neither read nor write the file.

@bpasero
Copy link
Member

bpasero commented Nov 4, 2020

@jrieken with your undo logic, you now read files before delete to support undo right? So I would expect an activation here.

@bpasero
Copy link
Member

bpasero commented Nov 7, 2020

I take it back, any IO operation whatsoever will activate the file system provider:

this._register(this._fileService.onWillActivateFileSystemProvider(e => {
e.join(this.activateByEvent(`onFileSystem:${e.scheme}`));
}));

Via

// Activate provider
await this.activateProvider(resource.scheme);

@github-actions github-actions bot locked and limited conversation to collaborators Dec 19, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
api feature-request Request for new features or functionality file-io File I/O
Projects
None yet
Development

No branches or pull requests

3 participants