Output from prompts and hooks should be saved to chat_dir

[sQVe]

Hey, 👋

First and foremost, thank you for an excellent plugin. I use it on a daily basis and it's improved my interaction with ChatGPT immensely.

My main workflow pain point with this plugin is the handling of all the unsaved No name buffers. Every time I close Neovim I need to confirm that I want to throw away a bunch of conversation buffers.

One way to solve this issue, that I can think of, is providing the ability to open the conversation buffers in a file that resides in a temporary folder, like /tmp/gp. This would allow me to target these buffers programmatically, to throw them away after a time timer etc. It would also allow me to find a conversation that I ran previously, if I threw it away by accident.

Do you have any thoughts on this, or recommendations on how to improve this workflow?

[isak102]

You can configure the directory that chats get opened in, using the chat_dir option: https://github.com/robitx/gp.nvim/blob/f2d9d751ad7e13c2740e0c599e6183f9951e34b7/lua/gp/config.lua#L97

[sQVe]

You can configure the directory that chats get opened in, using the chat_dir option: https://github.com/robitx/gp.nvim/blob/f2d9d751ad7e13c2740e0c599e6183f9951e34b7/lua/gp/config.lua#L97

Woah, how the hell did I miss that 😅🤦‍♂️ Thank you for the quick input!

I'll try that as soon as possible. Closing.

[sQVe]

@isak102 But hmmm... This is only for the chats right? I'm assuming it is since it has a default value.

My pain point is primarily with the output from prompts and hooks. These are not saved in a file by default.

Opening again.

[Robitx]

@sQVe hey, that's a good point, for buffers created with gp.Target.enew and such I've left it up to the users to decide where they want to store each file. This makes sense for stuff like generating unit tests, but the pool of hooks people come up with is much bigger.

There are four options how we could deal with enew/new/vnew: 1) current state, when the buffer has to be explicitly handled by the user before or during exit 2) unlisted scratch buffer, which gets erased the moment it stops being visible 3) listed scratch buffer, which can be hidden and return back to until the exit (during which they don't require any handling) 4) automatic backup of these into some new folder (since these are not chats)

Option 2) is a no - people switch buffers by accident and lose the generated data.

At the moment I'm inclined in the direction of 3) since the generated data is mostly useful at the given moment and after the work is done they lose value (especially since the context with which they were created is not included in the answer). What needs to be persisted still can be.

@sQVe whats your take on this?

[sQVe]

@Robitx Both option 3 and option 4 would be great. I'm happy as long as the prompt buffers don't need any action when closing Neovim.

[sQVe]

This makes sense for stuff like generating unit tests, but the pool of hooks people come up with is much bigger.

I would like to give some insights into my workflow. I have around 20 hooks that I use extensively. A sample would be: Atomic, Docstring, Compress, Tests, and Optimize. In addition to this I use GpEnew for ad hoc prompts.

Some of these I use in a chain, primarily when writing atomic notes for my second brain. I run a hook on a selection, and I then run a hook on the output, and etc. An example would be when I run the Atomic hook on a note I have. This hook typically splits the note into two of more. I then run Compress on each of the suggested notes to make sure the wording is concise and short.

I can quickly end up with 10 - 20+ No name buffers, as you probably can see. This is really annoying since I also frequently close and open Neovim. 😅

@Robitx I would greatly appreciate it if the solution we're discussing would apply on both hooks but also prompts (GpEnew and the sibling commands)

[Robitx]

@sQVe GpEnew etc. also use gp.Prompt function under the hood, so the solution covers both cases. Please try the latest version, if you deem it sufficient.

[sQVe]

@Robitx Works like a charm 🌟 Huge workflow improvement for me. Thank you for the quick fix!

Closing.