Bad XTerm Vim coloring

[Thomas Dickey]

On Mon, 24 Nov 2008, Nick Deubert wrote:

> On Mon, Nov 24, 2008 at 2:58 PM, Thomas Dickey <dickey@his.com> wrote:
>> On Mon, 24 Nov 2008, Nick Deubert wrote:
>>
>>> Hey everyone,
>>> First off thanks for your hard work on cygwin/X it is very
>>> appreciated. I upgraded to the new Xorg last week and I have had one
>>> really annoying issue ever since. Something about the new XTerm is
>>> messing up vim syntax coloring. With vim I have syntax on and
>>> background=dark and usually the coloring look like this:
>>> http://nd.dyndns.org:443/downloads/correct_coloring.PNG but now when I
>>> open a file in vim it looks like that for a split second then a ton of
>>> gibberish quickly scrolls in the right side of the vim ruler and when
>>> it stops my syntax is colors are all messed up and are colored like
>>> this: http://nd.dyndns.org:443/downloads/bad_coloring.PNG
>>>
>>> Now I think this is a problem with XTerm not vim because when I ssh
>>
>> I can't tell - but you can capture the output of vim using 'script' and
>> we can inspect the output of vim, to see if it is well-formed.
>
> I attached a vim.out(or you can get it here if you don't like

short: I don't know...
long: continue reading...

I made that readable with the 'unmap' program in my ncurses ftp-directory.
The problem is visible in the trace (though where the ultimate cause is,
is not yet clear).  Looking for the "+r", I see that is part of a control
sequence without the leading escape-character, e.g.,

\E[80;226H6
\E[1;5H
\E[80;227Hf
\E[1;5H
\E[80;218H[P1+r436f=
\E[1;5H

where \E's are escapes as in terminfo.  The \E's ending with "H" are 
cursor movement, so this fragment is sending something like

 	6f[P1+r436f=

I'd expect that vim is asking xterm for the strings that correspond to
different function-keys.  In ctlseqs.txt this text covers the response:

           xterm responds with DCS 1 + r Pt ST for valid requests, adding
           to Pt an = , and the value of the corresponding string that
           xterm would send, or DCS 0 + r Pt ST for invalid requests.
           The strings are encoded in hexadecimal (2 digits per charac-
           ter).

But DCS is missing (that would be "\EP" rather than "[P").  And the text
in vim.out is the text that xterm would be replying with.  The "436f"
is hex-encoded for "Co" (termcap number of colors).  Earlier in the
trace, vim has sent the control sequence asking for this information, e.g.

\EP+q436f
\E\\

On my Debian/testing, I've got vim 7.1.314, which is sending the same 
control sequence (and running xterm's test-script, I know that it's 
responding as I'd expect). There's no "+r" in a script running vim in 
xterm _here_.  Rereading your email, I also tried with .vimrc having
just

set syntax=on
set background=dark

but aside from seeing that the syntax coloring went away, didn't see
any change in the result - no "+r" in the script output.

> attachments: http://nd.dyndns.org:443/downloads/vim.out) which is what
> script outputted for this small test.c file:
> int main() {
>   char* blah = "blah\n";
>   return 0;
> }
>
>>
>> (While it's possible that cygwin's xterm is configured with different
>> options than on some other system, xterm should ignore - not echo -
>> well-formed control sequences that it doesn't understand).
>>
>> vim may talk to xterm to find what the function-keys send (I added a few
>> new keys in the last version or so, but vim "shouldn't" be confused by
>> that...).  Seeing exactly what was written to the xterm would give some
>> clues - along with finding what configure options were used to build
>> the cygwin package for xterm.
>
> I'm not sure how to see the configure options for xterm. It is the
> binary package 237-2 installed from mirrors.kernel.org.
>
> Just in case it means anything here is the vim configure options:
> :version
> VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Oct  9 2008 15:23:22)
> Compiled by corinna@cathi
> Huge 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
> +cryptv +cscope +cursorshape
> +dialog_con +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 +menu
> +mksession +modify_fname +mouse -mouseshape +mouse_dec -mouse_gpm
> -mouse_jsbterm +mouse_netterm
> -mouse_sysmouse +mouse_xterm +multi_byte +multi_lang -mzscheme
> -netbeans_intg -osfiletype
> +path_extra -perl +postscript +printer +profile -python +quickfix
> +reltime +rightleft -ruby
> +scrollbind +signs +smartindent -sniff +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: "$VIM/vimrc"
>     user vimrc file: "$HOME/.vimrc"
>      user exrc file: "$HOME/.exrc"
>  fall-back for $VIM: "/usr/share/vim"
> Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H     -g -O2
> Linking: gcc   -L/usr/local/lib -o vim.exe       -lm -lncurses  -liconv -lintl
>

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/