Tilix: REPLACE mode started at vim on "Synchronize Input"

[nean-and-i]

when opening a file via vim on centos 7, while "Synchronize Input" enabled, vim starts in REPLACE mode automatically ?!?!
this is not the case when using different terminal like terminator.
what triggers "shift+r" ?

[gnunn1]

I cannot reproduce this issue, it works as expected for me on Arch Linux. Anyone else have this problem?

[nean-and-i]

seriously, can be reproduced:
When I start 2 terminals and enable "Synchronize Input" and connect to 2 centos (CentOS Linux release 7.3.1611) boxes via ssh, and start vim to edit a file there eg. /etc/vimrc (VIM version 7.4.160), both vim starts in REPLACE mode.
When I disable synchronize Input, it does not happen, so it seems this mode interfere somehow with an default vim option.

I also figured out that the "set nocompatible" option somehow triggers the interfere ?!?!
if "set nocompatible" is disabled in 1 of the /etc/vimrc it works !!

[phw]

Also cannot reproduce. Tried on two remote Ubuntu 16.04 servers. It didn't matter if set compatible was active or not. Don't have a CentOS machine to test.

[nean-and-i]

no LXD,kvm,docker,virtualbox around?
you definitely need centos 7.3 on the dest. and its default vim.
haven't seen this issue on centos 6.
hard to reproduce but once you get there you'll wonder,...

you can also log into one centos 7 multiple times, enable Synchronize Input and just start vim .

[ivoarch]

I tried on my CentOS 7.3 and the same issue vim starts in REPLACE mode .
edit: img

[gnunn1]

Sorry for the delay in getting around to this, I can reproduce the problem in RHEL 7. When I run the vim command without synchronized input I see the following sequence (where the xt space commits are the ending of vim test.txt):

2017-05-22T16:34:55.787:terminal.d:__dgliteral16:977 2 Terminal Commit: x
2017-05-22T16:34:55.856:terminal.d:__dgliteral16:977 2 Terminal Commit: t
2017-05-22T16:34:56.832:terminal.d:__dgliteral16:977 2 Terminal Commit: 
2017-05-22T16:34:56.988:terminal.d:__dgliteral16:977 2 Terminal Commit: 
2017-05-22T16:34:56.988:terminal.d:__dgliteral16:977 2 Terminal Commit: [>1;4803;0c

However with synchronized input turned on I see the following:

2017-05-22T16:33:40.138:terminal.d:__dgliteral16:977 2 Terminal Commit: x
2017-05-22T16:33:40.138:terminal.d:__dgliteral16:977 1 Terminal Commit: x
2017-05-22T16:33:40.202:terminal.d:__dgliteral16:977 2 Terminal Commit: t
2017-05-22T16:33:40.202:terminal.d:__dgliteral16:977 1 Terminal Commit: t
2017-05-22T16:33:42.186:terminal.d:__dgliteral16:977 2 Terminal Commit: 
2017-05-22T16:33:42.187:terminal.d:__dgliteral16:977 1 Terminal Commit: 
2017-05-22T16:33:42.334:terminal.d:__dgliteral16:977 1 Terminal Commit: 
2017-05-22T16:33:42.334:terminal.d:__dgliteral16:977 2 Terminal Commit: 
2017-05-22T16:33:42.334:terminal.d:__dgliteral16:977 1 Terminal Commit: [>1;4803;0c
2017-05-22T16:33:42.335:terminal.d:__dgliteral16:977 2 Terminal Commit: [>1;4803;0c
2017-05-22T16:33:42.369:terminal.d:__dgliteral16:977 2 Terminal Commit: 
2017-05-22T16:33:42.369:terminal.d:__dgliteral16:977 1 Terminal Commit: 
2017-05-22T16:33:42.369:terminal.d:__dgliteral16:977 2 Terminal Commit: [>1;4803;0c
2017-05-22T16:33:42.369:terminal.d:__dgliteral16:977 1 Terminal Commit: [>1;4803;0c

So the sequence of  and [>1;4803;0c is repeated twice for both terminals. I have code that stops the terminal being accidentally synchronized with itself so I'm not sure why this is happening. Some more investigation required.

[gnunn1]

Hmm, I wonder if the issue is simply that vim is emitting those sequences and for some reason VTE is treating it as user input and triggering the commit event.

[f2404]

@gnunn1 Will you be able replicate the issue with another vte-based terminal?

[gnunn1]

@egmontkob Any thoughts on the why the commit signal in VTE is returning those escape signals as if they were user input?

[gnunn1]

I've worked around the issue by specifically looking for and ignoring synchronizing those sequences, i.e.:

if (text.endsWith("[2;2R") || text.endsWith("[>1;4803;0c")) return;

The problem no longer occurs but would be great to understand why VTE is reacting the way it does.

[gnunn1]

@f2404 Not easily, I would have to compile one and add an event handler for the commit signal to trace what it is generating. I highly doubt it's an issue with tilix though. Having said that, if you want to try reproducing with xfce4-terminal feel free, I'd be interested in your results.

[gnunn1]

Searching for the character string turns up the following vim issue report, not sure if it is related but seems like the same symptoms. Unfortunately I'm not super knowledgeable in vim to understand this deeply.

https://github.com/vim/vim/issues/183#issuecomment-132351311

[egmontkob]

\e[>1;4803;0c is the response to a \e[>c: whenever this latter is printed, the former is injected as if it was typed from the keyboard. Not sure about \e[2;2R, I'd have to dig into vim or vte, but it might be the same kind of story.

We've already discussed quite a few discrepancies with such vte signals and broadcast mode in general, I just can't remember where. Maybe here or xfce4-terminals's or terminator's bugtracker or at mainstream vte bugzilla.

E.g. one terminal is in normal cursor and/or keypad mode, the other one is in application cursor and/or keypad mode. Should it be the keypress that's repeated across terminals (and hence resolved to some (possibly different) escape sequence individually in each terminal) or should the escape sequence be repeated?

Same goes for copying and bracketed paste mode, should it be bracketed according to the "source" terminal's setting or the "target" one?

Similarly, one terminal is at its normal screen (where Shift+PageUp scrolls up), another one is at the alternate screen (where this key combo generates an escape sequence), what to do?

Apparently we've just observed that these kinds of vte-generated "fake" inputs also fall in this gray area. I don't know what the right behavior would be. Probably no-one thought this through. Probably the commit signal/event wasn't designed with broadcast mode in mind at all. I guess vte needs a generic cleanup around this topic...

[gnunn1]

Thanks @egmontkob for the input. Note I started with synchronizing based on keystrokes but then you opened that bug about typing in IME unicode not working. Changing the synchronization to using VTE's commit signal fixed that but it was somewhat more complicated as I now synchronize both. The commit signal is used for 99% of the input while the keystroke is used for any VTE hard-coded key sequences.

Generally this has worked quite well with this bug being the only notable exception.

I don't have any issues with leaving this as a workaround, just was curious if there was a more general approach I should take then looking for these two very specific sequences.

[egmontkob]

The more generic approach would be to come up with a proper specs and implementation in vte :D

[gnunn1]

@egmontkob lol, touche! Closing issue.

[nean-and-i]

thanks for the analysis and the fix!

[nean-and-i]

uuups,....

almost, almost, got weird escape characters now, after I exit vim while in synchronize modus,...

root@server:~> vim .ssh/id_rsa.pub 
^[[>1;4205;0c^[[>1;4205;0croot@server:~>

[nean-and-i]

it seems there is still "something" wrong, maybe related to #963 as well.
sometimes my terminal freezes on vim and I need to close the window, all this weird stuff wasn't the case in the early versions. I hope the root cause can be fixed soon.

[gnunn1]

Give me a day or two and I'll add a switch that restores the old way of doing synchronization so you can test it. The new way supports international entries which is nice but not at the expense of freezes. Thanks for reporting this.

[gnunn1]

This was easier then I thought. Try building the latest from master and see if it resolves your problem as I reverted the way synchronization works to the old way.

[nean-and-i]

wow, awesome!
I'd love to test it, I haven't setuped a compiling environment for this yet, so it could take a time on my side.

[gnunn1]

I can build you a version later tonight but you would need to install it manually.

[nean-and-i]

that would be perfect, thanks a lot!
manual install is not a problem.

[gnunn1]

I've uploaded a new build for you here:

http://gexperts.com/files/tilix.zip

Before installing it please uninstall your existing version. To install tilix manually, follow the instructions here:

https://gnunn1.github.io/tilix-web/

[nean-and-i]

Hi,
just worked the whole day with the test version,...
conclusion: not a single freeze nor a single ESC sequence fu**up whatsoever,...
from what I experienced everything in is working smooth again, even on centos 7 in conjunction with vim and synchro mode.

[gnunn1]

@nean-and-i Is it OK to close this issue now?

[nean-and-i]

yes, thanks for fixing !