Feature request: turn off bracketed paste mode permanently, BrPaste breaks editor session

[ghillb]

Hello,

if there currently isn't a way to turn off bracketed paste mode (BrPaste) in ConEmu permanently, it would be a nice feature to have.

I'm living in fear of ^[[201~. Because seeing it means that my vim session has become unusable after pasting something and I have to close vim and start over.

After researching, I found that the escape characters can be prevented from occurring when BrPaste is turned off in ConEmu. The only problem with this is that ConEmu always turns it back on and ^[[201~ randomly returns.

Versions

ConEmu build: 201011 x32/x64 OS version: Windows 10 x32/x64 Build 1809 ConEmu with WSL 1 - Ubuntu 20.04 with tmux, nvim 0.5, vi 8+

Problem description

bracketed paste escape characters occur and make vim unusable after pasting

Steps to reproduce

1. starting wsl in conemu
2. ssh to any remote linux machine and start editing in vim
3. waiting that bracketed paste sooner or later breaks vim session (can't close or ctrl+z even)

Actual results

BrPaste breaks vim sessions

Expected results

BrPaste can be disabled permanently

Additional files

[Maximus5]

Why vim session breaks? It should support bracketed paste properly.

[Maximus5]

Actually, if you have bracketed paste in Vim, you should disable it in Vim It's enabled/disabled with ansi posted from there: \e[?2004h and \e[?2004l. ConEmu just reacts to request of console app. Nothing to disable here.

[ghillb]

Actually, if you have bracketed paste in Vim, you should disable it in Vim It's enabled/disabled with ansi posted from there: \e[?2004h and \e[?2004l. ConEmu just reacts to request of console app. Nothing to disable here.

So in theory :execute 'silent !print "\e[?2004l"' should disable bracketed paste? Unfortunately it doesn't.

Why vim session breaks? It should support bracketed paste properly.

It breaks like in the bottom screenshot. When it happens keystrokes are not interpreted and the buffer gets spammed with ^Z, ^C, etc. Also there are "..." appearing in the command area. I'm trapped in insert mode.

I tried disabling bracketed paste via set t_BE= in my .vimrc but it is not working (https://vimhelp.org/term.txt.html#xterm-bracketed-paste).

[Maximus5]

Than either wrong place or smth. Have you checked t_BE value in vim?

[Maximus5]

And did you enable xterm in vim?

[ghillb]

An :echo &term yields xterm-256color. At this point, I suspect a vim plugin is responsible and I will take a deeper look to find it. But if that is the case, I would have to decide between the plugin and ConEmu (ConEmu would win of course). Unless there is a way to turn off bracketed paste in ConEmu altogether.

[stong]

I'm just going to leave a comment here so other users can find this issue from Google from keywords, and hopefully help them.

I also got this in GNU nano version 4.8 from Ubuntu 20.04. If I paste anything 21 chars or longer, like AAAAAAAAAAAAAAAAAAAAA, I get stuck in [ Unknown Sequence ] in nano. Doesn't happen in nano 2.9.3 from Ubuntu 18.04.

Interestingly if I paste AAAAAAAAAAAAAAAAAAAAA^M (21 A's then a newline), no problem. But without newline, will get stuck. If just paste 20 A's, no problem either.

Showkey indicates nothing weird is happening.

$ showkey -a

Press any keys - Ctrl-D will terminate this program

AAAAAAAAAAAAAAAAAAAAA    65 0101 0x41
         65 0101 0x41
         65 0101 0x41
         65 0101 0x41
         65 0101 0x41
         65 0101 0x41
         65 0101 0x41
         65 0101 0x41
         65 0101 0x41
         65 0101 0x41
         65 0101 0x41
         65 0101 0x41
         65 0101 0x41
         65 0101 0x41
         65 0101 0x41
         65 0101 0x41
         65 0101 0x41
         65 0101 0x41
         65 0101 0x41
         65 0101 0x41
         65 0101 0x41

Also, of course no problem if I disable BrPaste.

It seems this is because nano enabled bracketed paste in 4.8 https://savannah.gnu.org/bugs/?40060.

I would be really grateful if there is feature to disable bracketed paste

[stong]

Workaround: https://github.com/stong/ConEmu/commit/5fae3a293c5b751a6098a2a48a928ca2de5a2cab

Binaries https://github.com/stong/ConEmu/releases/tag/v21.09.05-workaround

This work around simply disables autodetection of BrPaste mode. If an application requests BrPaste mode, its request is ignored.

[dionysius]

I still have this issue today with ConEmu 210912 (what I get with cmder on scoop) on Windows 10 with nano on a ubuntu jammy. It's very annoying/unfortunate to have to restart the editing of the file :(

[wtarreau]

It just seems that recently a lot of programs have collectively decided to purposely break the compatibility with 50 years of well-working UNIX systems all over the world only to please a few selfish clueless beginners who were not able to properly disable/enable auto-indent in their editor, and that now thanks to them it's not possible anymore to use a modern linux system as a terminal to connect both to two remote systems, one which supports it (and ruins your session) and one which doesn't support it (i.e. the vast majority of deployed systems), so you just can't copy-paste text anymore between shells. Pffff... what a misery. The world is driven by morons and they're in the last step to try to kick us out of it :-(

I would just like permanent knobs to disable this utter crap from everywhere but that's not easy now that terminals like xterm support it. A single SSH to one corrupted host and you're done copy-pasting garbage into etc/hosts and so on...