scope conversations to the project

[phemmer]

Previously conversations were shared among all projects. However even this wasn't working correctly. For example, if you had an conversation in one project, but then opened another project, the conversation would be visible in both. But if you added messages to the conversation, it wouldn't update in the other project. Also sometimes you could open a project, and the conversations weren't there at all. And then if you closed that project, it would nuke the conversations in other projects.

This addresses the issues by making all conversations scoped to the project.

[carlrobertoh]

Making the conversations project-scoped is probably the best move. There's just one thing that worries me - will it still be possible to search, filter, and attach conversations from other projects to the context? Also, is this change backward-compatible? When updating the version, will the old conversations be carried over?

[carlrobertoh]

fyi: to make the conversations sync across all projects, you'll probably need to implement an application-level listener that handles the syncing - https://plugins.jetbrains.com/docs/intellij/plugin-listeners.html#defining-application-level-listeners

[phemmer]

will it still be possible to search, filter, and attach conversations from other projects to the context?

No. And this is opinionated, but I don't think it should be either. If a conversation is relevant to multiple projects, then it seems to me the correct solution there is that those projects shouldn't be separated, and that person should be using modules.

If we want to make the behavior configurable, so that the scoping can be disabled, it may be possible, but likely very difficult. What drove me to this was all the problems that were popping up because things weren't scoped, and I generally always have multiple projects open concurrently. Like what do we expect to happen when you have the same conversation in 2 projects, and you send a message? Should the message immediately become visible in both? As the response is streaming back, do we visually update both projects as the response is streamed? If you open a new tab, is a new tab opened on both projects? And what do we expect to happen when you have files added to the context, and those files don't exist in the other project?

Also another feature I had started on was state persistence. Often I'll be in a long running conversation with the LLM. I'll have several files added to the context, a message partially drafted, maybe a couple conversation tabs going on different subjects, etc. But then I'll need to restart the IDE for some reason, or it'll crash, etc, and all that is lost and I have to re-create the state. So I had added a change, where when the IDE is restarted, the tabs that were open will still be open. Any typed-but-unsent messages will be restored, along with the context files. And all this is done for all tabs. Doing this if the conversation is not scoped to the project is pretty much impossible.

Thus I think the only design decision that makes sense and would avoid all these issues is to scope everything to the project.

Also, is this change backward-compatible? When updating the version, will the old conversations be carried over?

No. If you want data migration, it can probably be added.

[carlrobertoh]

No. And this is opinionated, but I don't think it should be either. If a conversation is relevant to multiple projects, then it seems to me the correct solution there is that those projects shouldn't be separated, and that person should be using modules.

If the conversation becomes dependent to the project, then we should also clean up the search and filter logic.

When we talk about state persistence, then afaik you have only 2 available scopes - application and project scope. The way the conversations are currently stored is global, i.e. each conversation is shared across the IDE (application). I haven't heard of this modular persistence approach being used before. Can you give me a few more details on this one?

If we want to make the behavior configurable, so that the scoping can be disabled, it may be possible, but likely very difficult.

No, I don't think this behavior should be configurable.

Like what do we expect to happen when you have the same conversation in 2 projects, and you send a message? Should the message immediately become visible in both? As the response is streaming back, do we visually update both projects as the response is streamed? If you open a new tab, is a new tab opened on both projects? And what do we expect to happen when you have files added to the context, and those files don't exist in the other project?

The main intent behind this is to let users pull relevant chat context from other project chat sessions. This makes it extremely useful when you have multiple projects open that are dependent on each other.

No. If you want data migration, it can probably be added.

I don't think users will be very pleased about losing their earlier chat history upon update. Unfortunately, I don't have any good suggestions on how to handle this migration either. We do have a projectPath attached to each conversation that could be useful.

I have mixed feelings about this one. Having project-scope will definitely make things a lot easier. But then again, having the chat history accessible to every project makes it easy to share context between projects (when done right).

Idk, let's go with the project-scope approach I guess, but then please make sure to also clean up the filtering logic in the chat history tool window.

Btw, huge thanks for contributing! 🙏

[phemmer]

I haven't heard of this modular persistence approach being used before. Can you give me a few more details on this one?

It's not really related to persistence. Though you might be able to do it that way. But what I'm referring to is this:
https://www.jetbrains.com/help/idea/creating-and-managing-modules.html
That kinda explains it, but just to highlight, this kinda hits at the crux of the functionality:

IntelliJ IDEA allows you to have many modules in one project, and they do not all have to be Java. You can have one module for a Java application and another module for a Ruby on Rails application or for any other supported technology.

An application that consists of a client side and a server side is a good example of a two-module project.

So to me if someone is in a situation where they want conversations to span projects, I suspect they should be using one project with multiple modules. But this is just an assumption. There could be use cases I'm not thinking of.

When we talk about state persistence, then afaik you have only 2 available scopes - application and project scope. The way the conversations are currently stored is global, i.e. each conversation is shared across the IDE (application).

Yes, and this is currently problematic because the storage is shared, but not the runtime. And making the runtime shared would likely get very messy.

My other opinionated stance on this is that sharing state across the application doesn't even solve the problem. Like I personally use: Idea, PyCharm, CLion, GoLand, RustRover, DataGrip, & DataSpell. Every one of those would have their own conversation store. So I would only be able to share conversation across projects within the same one. And this is where my strong opinion comes in: If you can't do it right, don't do it at all.

I don't think users will be very pleased about losing their earlier chat history upon update.

Yes, and this seems perfectly reasonable. I can think of two ways of doing this.

1. A one-time migration where when the new plugin version is launched, it looks for the data and copies it into the new per-project store, treating it as if the project now owned that conversation, able to load it and continue using it (the global store would still remain, so other apps can also copy it).
2. A read-only view, where the plugin can show the historic conversations, but they cannot be resumed.

In both situations, we probably want a mechanism to delete from this old global store. Right now the history function doesn't have any control over what gets deleted. Your only option is to delete everything, which is a problem. Additionally, in option 1, where the historic conversation is copied into the project, this also becomes messy, all the conversations are migrated and shown as belonging to the project. You don't really have an interface into that legacy global store. Another consideration that might make option 2 more palatable, is that I've wanted conversation forking capability. Basically I want to be able to take an existing conversation, go to a specific message, and fork the conversation at that point. If this functionality existed, it could be used to fork those historic global conversations into the project scope.

Let me know what you prefer. I didn't have time to get back to this since the last round of PRs I submitted, but should have time now. And I've got another chain of PRs that will follow after this one. One adds the draft persistence I mentioned. And others with a ton of bug fixes, mostly around conversation persistence, loading, and handling of LLM code change diffs.