Skip to content

event handling for custom chat modes #250012

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

Merged
merged 3 commits into from
Jun 2, 2025
Merged

event handling for custom chat modes #250012

merged 3 commits into from
Jun 2, 2025

Conversation

aeschli
Copy link
Contributor

@aeschli aeschli commented May 28, 2025

No description provided.

@aeschli aeschli enabled auto-merge (squash) May 28, 2025 20:53
@aeschli aeschli self-assigned this May 28, 2025
@vs-code-engineering vs-code-engineering bot added this to the May 2025 milestone May 28, 2025
TylerLeonhardt
TylerLeonhardt previously approved these changes May 28, 2025
@aeschli aeschli merged commit d1e632d into main Jun 2, 2025
8 checks passed
@aeschli aeschli deleted the aeschli/many-deer branch June 2, 2025 09:57
}
}));
this._register(this.fileService.onDidFilesChange(e => {
if (e.affects(this.userDataService.currentProfile.promptsHome)) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aeschli this is problematic I think: the onDidFilesChange event is only firing for folders or files where you called fileService.watch. I think we are doing that here:

this._register(this.fileService.watch(this.promptsFolder));

But I would consider doing an explicit watch here to ensure the watcher is setup (multiple same watchers are folded into 1).

eventEmitter.fire();
return;
}
if (parentFolders.some(folder => e.affects(folder))) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aeschli I wonder how this can happen since the watching does not seem to be recursive.

@@ -55,6 +57,29 @@ export class PromptFilesLocator {
return files.filter(file => getPromptFileType(file) === type);
}

public getFilesUpdatedEvent(type: PromptsType): Event<void> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aeschli I find this a bit of a weird pattern to return an event from a method: esp. since you register disposables to the PromptFilesLocator, the lifecycle seems bound by "the big guy" and not the one calling it. This means you pile up listeners for as often as the method is called, only disposing them when "the big guy" goes away (likely never).

I would rather do 1 event that is fixed for the PromptsType to follow what we do in other places.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants