Bug 99041 - OpenSUSE Client 13.2 Vim Extraneous Lines Displayed, ESC Key Ignored
Summary: OpenSUSE Client 13.2 Vim Extraneous Lines Displayed, ESC Key Ignored
Status: RESOLVED MOVED
Alias: None
Product: XQuartz
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 2.7.11 (xserver-1.18.4)
Hardware: x86-64 (AMD64) Mac OS X (All)
: high major
Assignee: Jeremy Huddleston Sequoia
QA Contact: Jeremy Huddleston Sequoia
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-12-09 22:43 UTC by Dick Riegner
Modified: 2019-05-23 18:31 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Dick Riegner 2016-12-09 22:43:02 UTC
I am running XQuart 2.7.7 on a Mac OS X 10.11.6 system. I run an xterm on the Mac and ssh into my OpenSUSE 13.2 client machine at work.

I then edit a file using Vim 7.4.461 and notice that extraneous lines appear when I do an "o" or "O" command to insert a blank line. The extraneous lines come from directly above or below where I intend to insert the blank.

When I do an "i" to insert text, the "-- INSERT --" message is displayed in the lower left corner by Vim as expected. However, an ESC key then does not cause that message to be removed. It's as if the ESC key is being ignored.

When running an older Vim 7.3.315 this problems do not occur. But there are many differences between the newer version Vim 7.4.461 and older version 7.3.315. They have been built with substantially different options.

The older Vim is intended for servers, while the newer Vim is apparently intended for clients and supports the clipboard, xterm_clipboard, and X11 options. I believe these options allow easy cutting and pasting to other applications and are not enabled on the older server Vim 7.3.315.

I don't know if this problem is due to a bug in XQuartz on Mac OS X, a bug in X11 on my OpenSUSE system, or a bug in Vim. I suspect it is an XQuart bug because I am unable to reproduce this problem logging-in from other Linux variants to my OpenSUSE system at work.
Comment 1 Dick Riegner 2016-12-09 22:48:45 UTC
Actually I am running Xquartz 2.7.11.
Comment 2 Dick Riegner 2017-09-05 23:48:23 UTC
I continue to have problems running Vim on a remote system and displaying the output back to my iMac running Xquartz 2.7.11.  I now see the problem on other Linux systems when I edit a file from my xterm session on macOS 10.12.6.

I have tried changing the TERM environment variable in my Xquartz xterm session before logging into the remote system using scp.  I have tried TERM types of xterm, xterm-color, xterm-256color, ansi, linux, vt100, and vt220.  The display problems are not fixed with any of these different TERM types.

I then went back to TERM=xterm and tried logging in to the remote systems using the macOS Terminal application.  In all cases, I was able to correctly edit text files on all remote Linux systems using xterm as the terminal type.  Different levels of Vim on my workstation also worked with Terminal, but consistently fail with an Xquartz xterm.

This sure looks like some kind of compatibility issue between Vim and Xquartz.

I do not see any of these problems logging-in locally to various Linux systems from various other local Linux systems.  The problem only occurs when logging into these remotely from macOS running Xquartx.

Help resolving this problem will be much appreciated.
Comment 3 Dick Riegner 2017-09-07 18:13:21 UTC
This problem is becoming increasingly more important to me.  I am unable to
edit files on many of my remote Linux lab machines from an Xquartz xterm on macOS.

I am available to do debugging and testing as needed to fix this problem.

Thanks.

Dick Riegner
Comment 4 Dick Riegner 2017-09-08 19:08:25 UTC
I see the garbled Vim display when I login to my remote Linux system from an Xquartz xterm session.

However, if a login to the remote Linux system and launch an xterm session from that remote system, and display back to Xquartz, I do not see the garbled Vim text.

In both cases TERM is set to xterm.
Comment 5 Dick Riegner 2017-09-08 19:18:27 UTC
Another variable in this problem is the version of Vim that I run on my workstation from an xterm session on Xquartz.  The older Vim displays correctly, but the newer version garbles the text display.  This problem only happens with an xterm running on Xquartz on macOS.


Vim That Garbles Text Display
-----------------------------
VIM - Vi IMproved 7.4 (2013 Aug 10)
Included patches: 1-461
Compiled by 'http://www.opensuse.org/'
Huge version without GUI.  Features included (+) or not (-):
+acl             +farsi           +mouse_netterm   +syntax
+arabic          +file_in_path    +mouse_sgr       +tag_binary
+autocmd         +find_in_path    -mouse_sysmouse  +tag_old_static
-balloon_eval    +float           +mouse_urxvt     -tag_any_white
-browse          +folding         +mouse_xterm     -tcl
++builtin_terms  -footer          +multi_byte      +terminfo
+byte_offset     +fork()          +multi_lang      +termresponse
+cindent         +gettext         -mzscheme        +textobjects
+clientserver    -hangul_input    +netbeans_intg   +title
+clipboard       +iconv           +path_extra      -toolbar
+cmdline_compl   +insert_expand   +perl            +user_commands
+cmdline_hist    +jumplist        +persistent_undo +vertsplit
+cmdline_info    +keymap          +postscript      +virtualedit
+comments        +langmap         +printer         +visual
+conceal         +libcall         +profile         +visualextra
+cryptv          +linebreak       +python/dyn      +viminfo
+cscope          +lispindent      +python3/dyn     +vreplace
+cursorbind      +listcmds        +quickfix        +wildignore
+cursorshape     +localmap        +reltime         +wildmenu
+dialog_con      +lua/dyn         +rightleft       +windows
+diff            +menu            +ruby/dyn        +writebackup
+digraphs        +mksession       +scrollbind      +X11
-dnd             +modify_fname    +signs           +xfontset
-ebcdic          +mouse           +smartindent     -xim
+emacs_tags      -mouseshape      +sniff           +xsmp_interact
+eval            +mouse_dec       +startuptime     +xterm_clipboard
+ex_extra        -mouse_gpm       +statusline      -xterm_save
+extra_search    -mouse_jsbterm   -sun_workshop    -xpm
   system vimrc file: "/etc/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
  fall-back for $VIM: "/etc"
 f-b for $VIMRUNTIME: "/usr/share/vim/current"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H     -fomit-frame-pointer -fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=1 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall -pipe -fno-strict-aliasing      
Linking: gcc   -L. -fstack-protector -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.20.1/i586-linux-thread-multi/CORE   -L/usr/local/lib -Wl,--as-needed -o vim    -lSM -lICE -lXt -lX11 -lSM -lICE  -lm -lnsl    -ltinfo -lacl -lattr -ldl   -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.20.1/i586-linux-thread-multi/CORE  -fstack-protector  -L/usr/lib/perl5/5.20.1/i586-linux-thread-multi/CORE -lperl -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc   


Vim That Displays Text Correctly
--------------------------------
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Sep 21 2011 09:27:46)
Included patches: 1-315
Modified by <bugzilla@redhat.com>
Compiled by <bugzilla@redhat.com>
Small version without GUI.  Features included (+) or not (-):
-arabic -autocmd -balloon_eval -browse +builtin_terms -byte_offset -cindent 
-clientserver -clipboard -cmdline_compl +cmdline_hist -cmdline_info -comments 
-conceal -cryptv -cscope -cursorbind -cursorshape -dialog -diff -digraphs -dnd 
-ebcdic -emacs_tags -eval -ex_extra -extra_search -farsi -file_in_path 
-find_in_path -float -folding -footer +fork() -gettext -hangul_input +iconv 
-insert_expand +jumplist -keymap -langmap -libcall -linebreak -lispindent 
-listcmds -localmap -lua -menu -mksession -modify_fname -mouse -mouse_dec 
-mouse_gpm -mouse_jsbterm -mouse_netterm -mouse_sysmouse -mouse_xterm 
+multi_byte -multi_lang -mzscheme -netbeans_intg -path_extra -perl 
-persistent_undo -printer -profile -python -python3 -quickfix -reltime 
-rightleft -ruby -scrollbind -signs -smartindent -sniff -startuptime 
-statusline -sun_workshop -syntax -tag_binary -tag_old_static -tag_any_white 
-tcl +terminfo -termresponse -textobjects -title -toolbar -user_commands 
-vertsplit -virtualedit +visual -visualextra -viminfo -vreplace +wildignore 
-wildmenu +windows +writebackup -X11 -xfontset -xim -xsmp -xterm_clipboard 
-xterm_save 
   system vimrc file: "/etc/virc"
     user vimrc file: "$HOME/.vimrc"
      user exrc file: "$HOME/.exrc"
  fall-back for $VIM: "/etc"
 f-b for $VIMRUNTIME: "/usr/share/vim/vim73"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H     -O2 -g -pipe -Wall  -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64  -D_FORTIFY_SOURCE=1      
Linking: gcc   -L/usr/local/lib -Wl,--as-needed -o vim       -lm  -lselinux -lncurses -lacl -lattr -ldl
Comment 6 Dick Riegner 2017-09-11 17:19:55 UTC
Can someone help with this bug?  I have not seen a response to any of my posts.

Thanks.
Comment 7 Dick Riegner 2017-09-11 17:21:08 UTC
Resting assignee and QA Contact.
Comment 8 Dick Riegner 2017-09-26 04:25:26 UTC
Changing the TERM environment variable from "xterm" to "screen" on my Linux workstation causes vim 7.4 to now properly display its text back to Xquartz on macOS.

Here is the difference between the "xterm" and "screen" terminal definitions in terminfo on my workstation:

infocmp -d xterm screen
comparing xterm to screen.
    comparing booleans.
        bce: T:F.
        mc5i: T:F.
        npc: T:F.
    comparing numbers.
        ncv: NULL, NULL.
    comparing strings.
        acsc: '``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~', '++\,\,--..00``aaffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~'.
        clear: '\E[H\E[2J', '\E[H\E[J'.
        cnorm: '\E[?12l\E[?25h', '\E[34h\E[?25h'.
        cuu1: '\E[A', '\EM'.
        cvvis: '\E[?12;25h', '\E[34l'.
        dim: '\E[2m', NULL.
        ech: '\E[%p1%dX', NULL.
        enacs: NULL, '\E(B\E)0'.
        flash: '\E[?5h$<100/>\E[?5l', '\Eg'.
        hpa: '\E[%i%p1%dG', NULL.
        indn: '\E[%p1%dS', NULL.
        invis: '\E[8m', NULL.
        is2: '\E[!p\E[?3;4l\E[4l\E>', '\E)0'.
        kDC: '\E[3;2~', NULL.
        kEND: '\E[1;2F', NULL.
        kHOM: '\E[1;2H', NULL.
        kIC: '\E[2;2~', NULL.
        kLFT: '\E[1;2D', NULL.
        kNXT: '\E[6;2~', NULL.
        kPRV: '\E[5;2~', NULL.
        kRIT: '\E[1;2C', NULL.
        kb2: '\EOE', NULL.
        kend: '\EOF', '\E[4~'.
        kent: '\EOM', NULL.
        kf13: '\E[1;2P', NULL.
        kf14: '\E[1;2Q', NULL.
        kf15: '\E[1;2R', NULL.
        kf16: '\E[1;2S', NULL.
        kf17: '\E[15;2~', NULL.
        kf18: '\E[17;2~', NULL.
        kf19: '\E[18;2~', NULL.
        kf20: '\E[19;2~', NULL.
        kf21: '\E[20;2~', NULL.
        kf22: '\E[21;2~', NULL.
        kf23: '\E[23;2~', NULL.
        kf24: '\E[24;2~', NULL.
        kf25: '\E[1;5P', NULL.
        kf26: '\E[1;5Q', NULL.
        kf27: '\E[1;5R', NULL.
        kf28: '\E[1;5S', NULL.
        kf29: '\E[15;5~', NULL.
        kf30: '\E[17;5~', NULL.
        kf31: '\E[18;5~', NULL.
        kf32: '\E[19;5~', NULL.
        kf33: '\E[20;5~', NULL.
        kf34: '\E[21;5~', NULL.
        kf35: '\E[23;5~', NULL.
        kf36: '\E[24;5~', NULL.
        kf37: '\E[1;6P', NULL.
        kf38: '\E[1;6Q', NULL.
        kf39: '\E[1;6R', NULL.
        kf40: '\E[1;6S', NULL.
        kf41: '\E[15;6~', NULL.
        kf42: '\E[17;6~', NULL.
        kf43: '\E[18;6~', NULL.
        kf44: '\E[19;6~', NULL.
        kf45: '\E[20;6~', NULL.
        kf46: '\E[21;6~', NULL.
        kf47: '\E[23;6~', NULL.
        kf48: '\E[24;6~', NULL.
        kf49: '\E[1;3P', NULL.
        kf50: '\E[1;3Q', NULL.
        kf51: '\E[1;3R', NULL.
        kf52: '\E[1;3S', NULL.
        kf53: '\E[15;3~', NULL.
        kf54: '\E[17;3~', NULL.
        kf55: '\E[18;3~', NULL.
        kf56: '\E[19;3~', NULL.
        kf57: '\E[20;3~', NULL.
        kf58: '\E[21;3~', NULL.
        kf59: '\E[23;3~', NULL.
        kf60: '\E[24;3~', NULL.
        kf61: '\E[1;4P', NULL.
        kf62: '\E[1;4Q', NULL.
        kf63: '\E[1;4R', NULL.
        kfnd: '\E[1~', NULL.
        khome: '\EOH', '\E[1~'.
        kind: '\E[1;2B', NULL.
        kri: '\E[1;2A', NULL.
        kslt: '\E[4~', NULL.
        mc0: '\E[i', NULL.
        mc4: '\E[4i', NULL.
        mc5: '\E[5i', NULL.
        nel: NULL, '\EE'.
        rin: '\E[%p1%dT', NULL.
        ritm: '\E[23m', NULL.
        rmacs: '\E(B', '^O'.
        rmam: '\E[?7l', NULL.
        rmm: '\E[?1034l', NULL.
        rmso: '\E[27m', '\E[23m'.
        rs1: '\Ec', NULL.
        rs2: '\E[!p\E[?3;4l\E[4l\E>', '\Ec\E[?1000l\E[?25h'.
        setb: '\E[4%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m', NULL.
        setf: '\E[3%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m', NULL.
        sgr: '%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p5%t;2%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m', '\E[0%?%p6%t;1%;%?%p1%t;3%;%?%p2%t;4%;%?%p3%t;7%;%?%p4%t;5%;m%?%p9%t\016%e\017%;'.
        sgr0: '\E(B\E[m', '\E[m\017'.
        sitm: '\E[3m', NULL.
        smacs: '\E(0', '^N'.
        smam: '\E[?7h', NULL.
        smm: '\E[?1034h', NULL.
        smso: '\E[7m', '\E[3m'.
        u6: '\E[%i%d;%dR', NULL.
        u7: '\E[6n', NULL.
        u8: '\E[?1;2c', NULL.
        u9: '\E[c', NULL.
        vpa: '\E[%i%p1%dd', NULL.
Comment 9 Dick Riegner 2017-09-27 16:48:05 UTC
Note that the vim 7.4 text display corruption is only seen when displaying back to Xquartz running on macOS.  

The vim 7.4 text display is always correct when running and displaying on numerous desktop and server systems running X11 on Linux.
Comment 10 Dick Riegner 2017-10-30 21:11:41 UTC
Is there anything more I can do or provide to help fix this problem?
Comment 11 Dick Riegner 2018-01-17 19:14:38 UTC
It looks like someone else is also seeing the display corruption when running vi remotely on a Linux system and displaying back to Xquartz on macOS.


https://stackoverflow.com/questions/46919687/vi-display-messed-up-in-remote-servers-using-xquartz


And they too have apparently not resolved the problem.

I am going to try running with TERM set to xterm-new on macOS.
Comment 12 Dick Riegner 2018-03-08 20:40:34 UTC
In the past 6 weeks, I am no longer able to reproduce this problem and have not seen any of the extraneous lines when editing a file.  I can now correctly edit files with the current vi installed with openSUSE 13.3.  I no longer need to revert to a much older vi version.

I have not recently changed my office Linux workstation hardware or software in over a year that runs the now unsupported openSuSE 13.3.

I have not recently changed my home iMac hardware or software that has been running macOS 10.12.6 for over several months.

I do know that our corporate VPN network has been changed, and continues to change, over the past 2 months.  I suspect that maybe the VPN connection was the cause of this problem, but that is mostly speculation at this time.

In any event, the problem no longer occurs, and I can now correctly edit using the current vi on openSUSE 13.3 executed from an XQuartz xterm on macOS.
Comment 13 Dick Riegner 2018-06-07 17:34:38 UTC
I found this work-around for the corrupt edit session display when running vi/vim on a remote Linux system and displaying back to XQuartz on macOS.  Thanks to Norm Wood for his work-around posted here:

http://vim.1045645.n5.nabble.com/Corrupt-display-when-editing-remotely-via-ssh-td5730732.html

His work-around is to reset the vi/vim "term" value after starting a vi/vim edit session.  This example uses an "xterm" terminal session:

:set term=xterm

I made the work-around more permanent by adding these statements to my ~/,vimrc file:

" Work-around for garbage/corrupt edit display back to
" macOS XQuartz (X11) server with newer vi/vim
if (&term == 'xterm')
 set term=dummy
 set term=xterm
endif

This problem does not occur when displaying back to any of our X11 servers running on Linux.

I still do not know the root cause of this problem nor have an actual fix for it.
Comment 14 Dick Riegner 2018-08-10 17:35:41 UTC
I consistently see text display corruption when 
editing a file on a remote Linux system with vim.  

I run an xterm window on macOS and ssh into a 
remote Linux machine.  The edit session is 
displayed back to an XQuartz server running on 
the same macOS.

I have only seen this problem when displaying 
back to an XQuartz server running on macOS.  

I have not seen the problem when displaying back
to an X11 server running on various Linux 
systems.

This problem occurs with newer versions of vim,
but not older versions.

Inserting lines causes the INSERT message to be 
displayed in the command line, but it is not 
cleared after hitting the ESC key.  

Inserting text also causes extraneous lines of 
text to be added to the body of the original 
text, corrupting the edit display.

I suspect that I am seeing the same vim behavior
as was reported in this incident:

https://groups.google.com/forum/#!topic/vim_dev/GR9YG8TZy6o

A work-around is to add this statement to the 
.vimrc file:

set ambiwidth=single

I do not know if this is a bug in vim, XQuartz, 
or both.  So I am asking for XQuartz help here 
and vim help in another forum.
 
Here is a summary of editing a file using two 
versions of vim, each with and without, the 
ambiwidth work-around.


New Vim
-------
VIM - Vi IMproved 7.4 (2013 Aug 10)
Included patches: 1-207, 209-326
Compiled by 'http://www.opensuse.org/'

Works with:     set ambiwidth=single
Fails without:  set ambiwidth=single


Old Vim
-------
VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Feb  4 2012 09:50:29)
Included patches: 1-108
Compiled by 'http://www.opensuse.org/'

Works with:     set ambiwidth=single
Works without:  set ambiwidth=single
Comment 15 GitLab Migration User 2019-05-23 18:31:37 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/778.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.