Skip to content

feat: add 'termsync' setting#19541

Closed
64-bitman wants to merge 1 commit intovim:masterfrom
64-bitman:termsync
Closed

feat: add 'termsync' setting#19541
64-bitman wants to merge 1 commit intovim:masterfrom
64-bitman:termsync

Conversation

@64-bitman
Copy link
Contributor

@64-bitman 64-bitman commented Mar 1, 2026

Same as Neovim's termsync option. Surprised this wasn't already added, considering how simple it was to implement (unless I'm missing something) and it reduces flickering greatly for me on my machine.

Here's a before and after comparsion:

2026-03-01.13-31-14.mp4

@64-bitman 64-bitman force-pushed the termsync branch 7 times, most recently from 4525f76 to 32d75e4 Compare March 2, 2026 03:11
@zeertzjq zeertzjq changed the title feat; add 'termsync' setting feat: add 'termsync' setting Mar 2, 2026
@64-bitman 64-bitman force-pushed the termsync branch 7 times, most recently from af717ea to 417d677 Compare March 2, 2026 04:50
@64-bitman
Copy link
Contributor Author

64-bitman commented Mar 2, 2026

I found #11718 which this PR is related to, seems like bram did not get the point of something like this. However it has noticeably reduces flickering for me, so I guess there is a point.

I think this is ready

@chrisbra
Copy link
Member

chrisbra commented Mar 2, 2026

out_str((char_u *)"\033[?2026$p");

Hm, we typically have those as t_<letter> options. Don't we need this here as well instead of hard coding this?

@JavierJF
Copy link
Contributor

JavierJF commented Mar 2, 2026

This PR fixes the popup flickering, but does it as a side effect of the feature, also since it only does it for terminal that supports this feature, I think that having correctness back for popups without transparencies is important. So opaque popups don't require terminals with this feature to avoid rendering issues, while popups with transparencies will require it for avoiding flickering.

Due to this, I think that even with this PR, the with changes from #19534 are still required. Said this, I think it's a great feature to have 👍 .

@64-bitman
Copy link
Contributor Author

64-bitman commented Mar 2, 2026

out_str((char_u *)"\033[?2026$p");

Hm, we typically have those as t_<letter> options. Don't we need this here as well instead of hard coding this?

Well it looks to me that all terminals that support synchronized output use this same escape sequence. However I think it is a good idea to add a t_ option for consistency

The synchronized output does not use termcap to check if it is available, so I don't think we need a t_ option, but maybe for the other escape sequences would be a good idea.

@64-bitman 64-bitman force-pushed the termsync branch 3 times, most recently from 41d6c3c to a089f84 Compare March 2, 2026 21:46
@64-bitman
Copy link
Contributor Author

64-bitman commented Mar 2, 2026

Okay I have made it so the escape codes to begin and end synchronized output are configurable by the user. I left the \033[?2026$p escape code hardcoded, because all terminals that support synchronized output use this, and it makes things simpler (esp. when detecting the response).

@chrisbra
Copy link
Member

chrisbra commented Mar 3, 2026

Does this the same as in Neovim? If yes, I assume we cannot change the naming? Because if I hear termsync I associate this setting with :terminal. But that is not the case.
On the other hand, this is not true:

:h 'term<c-d>
'term'           'termbidi'       'termwinkey'     'termwinsize'    'termwintype'    'termencoding'   'termguicolors'  'termwinscroll'

@64-bitman
Copy link
Contributor Author

Does this the same as in Neovim? If yes, I assume we cannot change the naming? Because if I hear termsync I associate this setting with :terminal. But that is not the case.

On the other hand, this is not true:


:h 'term<c-d>

'term'           'termbidi'       'termwinkey'     'termwinsize'    'termwintype'    'termencoding'   'termguicolors'  'termwinscroll'

I named it termsync because that's what it is named in Neovim. However I suppose we can change the name to something like syncout. What do you think?

@chrisbra
Copy link
Member

chrisbra commented Mar 3, 2026

let's keep it the same as in Neovim

@h-east
Copy link
Member

h-east commented Mar 4, 2026

let's keep it the same as in Neovim

Yes. Since it is essentially a control for the terminal, I think the term prefix is ​​fine.

@64-bitman
Copy link
Contributor Author

I think this is ready

@chrisbra
Copy link
Member

chrisbra commented Mar 4, 2026

thanks

@chrisbra chrisbra closed this in 7ba60f1 Mar 4, 2026
chrisbra added a commit that referenced this pull request Mar 5, 2026
related: #19541

Signed-off-by: Christian Brabandt <cb@256bit.org>
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