[vim/vim] Odd characters when piping from command line (#6111)
yjfguhd
With a clean Vim, I am seeing unwanted output when piping from the command line. I'm told v8.2.0767 introduced this regression.
vim -Nu NONE- Enter "echo hello" into the buffer
- Run it through bash:
:w !bash
I expect to see a "hello" clearly displayed.
Instead, I see this (using od so we can see if there are any extra characters there.) in terminator, and this in xterm.
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled May 21 2020 14:10:56)
Included patches: 1-803
Slackware 14.2
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Tony Mechelynck
What does Vim answer to the following (with the cursor on "echo hello")?
verbose set enc? fenc? bomb?
(the question marks are part of the command)
I suspect encoding=utf-8 fileencoding=utf-8 bomb
In that case, does the problem still happen after
:setlocal nobomb
? With me it does before but not after.
Best regards,
Tony.
Dominique Pellé
I can reproduce it with the latest vim-8.2.803 on
xubuntu-18.03, with xfce4-terminal and gnome-terminal,
which print:
$ ./vim --clean -c ':call setline(1, "echo hello")' -c 'w !bash'
�[>4;mhello
And also with xterm which prints ello instead of hello:
$ ./vim --clean -c ':call setline(1, "echo hello")' -c 'w !bash'
ello
In reply to @tonymec: it's got nothing to do with 'nobomb'
since it happens when starting vim with: vim --clean.
Tony Mechelynck
With vim --clean in konsole I get the expected result, but in xterm I get ello. What is strange is that with
echo 1 2 3 4 5 6 hello
I still get "ello" in xterm. OTOH, |od -tx1 gives a different (higher) count for echo 1 2 3 4 5 6 hello than for plain echo hello; but the count does not agree to what it types.
Best regards,
Tony.
Dominique Pellé
To @tonymec
Since you can reproduce the issue with xterm, what Linux distribution do you use?
I'm asking as the spurious characters after 8.2.0767 affects at least Ubuntu-18.04 and Slackware 14.2. I'm curious whether it affects other distributions.
What version of xterm do you use?
For me on Ubuntu-18.04 (where I also see the issue), I have:
$ xterm -v
XTerm(330)
Tony Mechelynck
wrote:
> To @tonymec <https://github.com/tonymec>
>
> Since you can reproduce the issue with xterm, what Linux distribution do
> you use?
> I'm asking as the spurious characters after 8.2.0767 affects at least
> Ubuntu-18.04 and Slackware 14.2. I'm curious whether it affects other
> distributions.
>
> <https://github.com/yjfguhd>
>
> What version of xterm do you use?
> For me on Ubuntu-18.04 (where I also see the issue), I have:
>
> $ xterm -v
> XTerm(330)
>
>
and its v:termresponse is ^[[>41;330;0c
Best regards,
Tony.
Gary Johnson
> I can reproduce it with the latest vim-8.2.803 on
> xubuntu-18.03, with xfce4-terminal and gnome-terminal,
> which print:
>
> $ ./vim --clean -c ':call setline(1, "echo hello")' -c 'w !bash'
>
> �[>4;mhello
>
>
> And also with xterm which prints ello instead of hello:
>
> $ ./vim --clean -c ':call setline(1, "echo hello")' -c 'w !bash'
>
> ello
"[>4;m" problem. I observe it when using GNOME Terminal, but not
when using xterm or mintty.
The "<esc>[>4;m" sequence is the modifyOtherKeys reset sequence.
According to a number of articles found on the Web*, GNOME Terminal
does not support modifyOtherKeys and is not likely to.
xfce4-terminal returns the same v:termresponse sequence as GNOME
Terminal, so I would expect xfce4-terminal to have the same
shortcomings as GNOME Terminal.
If Vim is going to continue to support modifyOtherKeys, then it
should identify terminals that don't support it and not send that
sequence to those terminals. In my experience, v:termresponse has
been a reliable indicator of actual terminal type. The problem with
it is that Vim doesn't know its value until after vimrc has been
processed, so one has to defer some terminal-dependent processing to
a TermResponse autocommand, which has its own problems.
What I do is have my ~/.bashrc query the terminal for its
termresponse, save that in the environment variable TERMRESPONSE,
and use that value to make terminal-dependent selections in my vimrc
and color scheme files.
Alternatively, a GNOME Terminal user could set TERM=gnome, which is
supposed to be a more accurate terminfo entry for a GNOME Terminal.
The user could set TERM=gnome if COLORTERM=gnome-terminal. Vim
could then use TERM=gnome or COLORTERM=gnome-terminal as a condition
for disabling modifyOtherKeys.
I've been testing this on an Ubuntu 18.04 system with Vim 8.2.803,
xterm version 344 and GNOME Terminal version 3.28.2, as well as
remotely over ssh from a Windows 10 system running Cygwin with
mintty 3.1.5.
Regards,
Gary
----------
* https://unix.stackexchange.com/questions/165104/does-gnome-terminal-have-an-equivalent-for-xterms-modifyotherkeys
https://bugzilla.gnome.org/show_bug.cgi?id=477068
https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/96676
https://invisible-island.net/xterm/xterm.faq.html#bug_gnometerm
vim-dev ML
Tony Mechelynck
If you know that some terminal doesn't support modifyOtherKeys, then when running in that terminal (and with has('gui_running') being false) you can set t_TI and T_TE to empty to avoid using that facility. Or if you can find some terminal name correctly describing that terminal in the termcap/terminfo database, and with those two codes empty, so much the better.
Best regards,
Tony.
—
You are receiving this because you commented.
Bram Moolenaar
Unless we can recognize the broken version, I would rather just tell
users to not use a broken terminal.
--
hundred-and-one symptoms of being an internet addict:
187. You promise yourself that you'll only stay online for another
15 minutes...at least once every hour.
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
vim-dev ML
yjfguhd
So, to summarise, this is a bug with the terminal emulator, not an issue with Vim, so can't/won't be fixed by Vim, and until one's terminal emulator is fixed, a workaround for seeing thie behaviour in Vim is to unset t_TI and t_TE?
—
You are receiving this because you commented.
Bram Moolenaar
With the latest Vim I cannot reproduce this problem, neither in xterm or in gnome-terminal.
—
You are receiving this because you commented.
Christian Brabandt
Bhramar-vatsa
I stumbled upon this page for the solution of the issue, but found that setting t_TI and t_TE to empty doesn't work. So, I would like to add (for someone like me) that a solution stated at https://stackoverflow.com/a/75432130 to do following works:
set keyprotocol=
let &term=&term
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.