Skip to content

improving chat behaviour within a tab#207

Merged
madox2 merged 2 commits intomainfrom
tab-local-chat
Mar 9, 2026
Merged

improving chat behaviour within a tab#207
madox2 merged 2 commits intomainfrom
tab-local-chat

Conversation

@madox2
Copy link
Owner

@madox2 madox2 commented Mar 7, 2026

No description provided.

@Konfekt
Copy link
Contributor

Konfekt commented Mar 8, 2026

Maybe there's a misunderstanding. The idea is that of a toggle inside one fixed tab, the same >>> AI chat 8 opening on :AIChat. With this PR, a new buffer >>> AI chat 9 ... is opened on every :AIChat after closing the window.

@madox2
Copy link
Owner Author

madox2 commented Mar 8, 2026

It should work only if scratch_buffer_keep_open is enabled. Also inside a new tab it needs to spawn new instance of chat manually, e.g. by :AIC /right and then any consequent :AIC should use that spawned instance in the tab even if window is closed.

@Konfekt
Copy link
Contributor

Konfekt commented Mar 8, 2026

I had this setting set

let g:vim_ai_chat = {
\  "ui": {
\    "scratch_buffer_keep_open": 1,
\  },
\ }

to the described effect. I'm using :AIChat, :close and :AIChat will open a new buffer with increased number label. In the now closed PR, the closed buffer would resurface again, same number label

@Konfekt
Copy link
Contributor

Konfekt commented Mar 8, 2026

Would you mind comparing it to former #203 ?

@madox2
Copy link
Owner Author

madox2 commented Mar 8, 2026

Hi, I tried to reproduce exactly as you described but it works as expected. Even from the fact how scratch_buffer_keep_open = 1 works it will never spawn a new istance of the chat, unless you use ui.force_new_chat, but you didn't mention that. Also attaching screencast.
tab_local_chat

@Konfekt
Copy link
Contributor

Konfekt commented Mar 9, 2026

terminal-20260309-070020

The idea of #204 was that on the second :AIChat the entered text aaa in the buffer would resurface

@madox2
Copy link
Owner Author

madox2 commented Mar 9, 2026

I can't reproduce, did everything as you in the gif video and it works as expected. By any chance don't you use force_new_chat in a default configuration/role or have some custom function? If not, can you try it in a clean vim without plugins and with default vim-ai configuration?

@Konfekt
Copy link
Contributor

Konfekt commented Mar 9, 2026

In the tab-local-chat branch with

let &rtp = '~/.vim/plugged/vim-ai' . ',' . &rtp
filetype plugin indent on
syntax on
let g:vim_ai_chat = {
      \  "ui": {
      \    "scratch_buffer_keep_open": 1,
      \  },
      \ }

terminal-20260309-165015

With

let &rtp = '~/.vim/plugged/vim-ai' . ',' . &rtp
filetype plugin indent on
syntax on

terminal-20260309-165201

In this branch scratch_buffer_keep_open will throw shown errors, without it, the buffer is reset.
Instead, the idea of #203 is that the same buffer where aaa was entered will resurface.

@madox2
Copy link
Owner Author

madox2 commented Mar 9, 2026

Okay, that's a good catch, I fixed the error. You can try now

@Konfekt
Copy link
Contributor

Konfekt commented Mar 9, 2026

Same as before,

the buffer is reset.
Instead, the idea of #203 is that the same buffer where aaa was entered will resurface.

@Konfekt
Copy link
Contributor

Konfekt commented Mar 9, 2026

terminal-20260309-205043

@madox2
Copy link
Owner Author

madox2 commented Mar 9, 2026

You obviously don't have clean vim-ai configuration, because the default chat is not supposed to open in the right panel. So I guess there is some misconfiguration on your side. Well clean config but scratch_buffer_keep_open enabled

@Konfekt
Copy link
Contributor

Konfekt commented Mar 9, 2026

In #203 it also works with dirty configuration; why shouldn't it? What's the win here?

@madox2 madox2 merged commit d751b87 into main Mar 9, 2026
1 check passed
@Konfekt
Copy link
Contributor

Konfekt commented Mar 9, 2026

For the record, "open_chat_command": "preset_right", was enabled

@madox2
Copy link
Owner Author

madox2 commented Mar 9, 2026

I was trying to find out why it is not working for you when it obviously should. If you can't reproduce it on the clean configuration, then it points to your "dirty configuration", otherwise is the problem somewhere else in your environment. Anyway, I tested it on different environments with different kind of setup, should be working, I not going to invest more time into this.

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.

2 participants