Possible bug in matchparen.vim relating to terminals/tmux/GNU screen
Marc Abramowitz
eliminated it by disabling matchparen.vim
The bug happens when I'm using vim in an ssh session (to a Linux
machine) with GNU Screen or tmux (on the server) in iTerm2.app or
Terminal.app on Mac OS X and editing PHP code. If I type "require
dirname(__FILE__) .", then after typing the closing parenthesis, the
screen gets corrupted such that it looks like I typed "require
dirnam((__FILE_))" (missing "e"). Hitting Control-L refreshes the
screen of course, but it's irritating nonetheless.
Yesterday, I got the bug to disappear by putting this in my
~/.vimrc.local (I'm using Janus):
" vim's parenthesis highlighting causes screen corruption when vim is
running
" inside GNU screen or tmux?
let loaded_matchparen = 1
I don't know if this is a bug in matchparen.vim or something else.
If I type slowly, it looks like after typing the closing parenthesis,
both the opening and closing parenthesis are highlighted correctly.
Things go haywire after typing a space after the closing parenthesis.
It looks like it's attempting to replace the highlighted open
parenthesis with a normal parenthesis but it does it one cursor
position to the left, resulting in the "e" in dirname getting
overwritten with a parenthesis and the highlighted open parenthesis is
still present next to it.
Here's a screenshot: http://cl.ly/1E1I2X0t3e1F3c3F2I2J
If I understood more clearly what the problem is, then I'd try to fix
it and submit a patch, but I'm not very knowledgable about terminal
issues. If someone points me in the right direction, I might be able
to come up with a patch...
Thanks,
Marc
Marc Abramowitz
> The bug happens when I'm using vim in an ssh session (to a Linux
> machine) with GNU Screen or tmux (on the server) in iTerm2.app or
> Terminal.app on Mac OS X and editing PHP code. If I type "require
> dirname(__FILE__) .", then after typing the closing parenthesis, the
> screen gets corrupted such that it looks like I typed "require
> dirnam((__FILE_))" (missing "e"). Hitting Control-L refreshes the
> screen of course, but it's irritating nonetheless.
OK, I played around a bit more and I've reduced this to the smallest
possible case.
The root of the problem appears to be that Janus sets listchars with a
UTF-8 encoded Unicode character, namely U+00B7 or "MIDDLE DOT" which
is encoded as "0xc2 0xb7" in UTF-8.
marca@web01:/home/marca$ cat ~/.vimrc
set encoding=utf-8
set list listchars=tab:\ \ ,trail:·
marca@web01:/home/marca$ hexdump -C ~/.vimrc
00000000 73 65 74 20 65 6e 63 6f 64 69 6e 67 3d 75 74 66 |set
encoding=utf|
00000010 2d 38 0a 73 65 74 20 6c 69 73 74 20 6c 69 73 74 |-8.set
list list|
00000020 63 68 61 72 73 3d 74 61 62 3a 5c 20 5c 20 2c 74 |chars=tab:
\ \ ,t|
00000030 72 61 69 6c 3a c2 b7 0a |rail:...|
00000038
marca@web01:/home/marca$ python
>>> middle_dot = u'\xb7'
>>> print middle_dot.encode('utf-8')
·
>>> middle_dot.encode('utf-8')
'\xc2\xb7'
My guess at this point would be that matchparen.vim has some code in
it that is not multi-byte aware.
Marc
Bram Moolenaar
Marc Abramowitz wrote:
matchparen.vim is a Vim script, it can't really mess up the display.
I tried this in an ssh session and it looks fine to me. I suspect there
is something in your terminal setup that causes the problem.
First thing to check if the value of 'term' is correct.
--
TALL KNIGHT: We shall say Ni! again to you if you do not appease us.
ARTHUR: All right! What do you want?
TALL KNIGHT: We want ... a shrubbery!
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// 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 ///
Christ van Willegen
Hi,
Not sure if this is related...
When I'm editting code ia SSH on an Ubuntu 11.10 machine, the screen is messed up very easily if I use anything but width 80. Ctrl-l fixes it temporarily.
I'm not using listchars. What can I do to tey to reproduce this?
Christ van Willegen
Tony Mechelynck
Yes, a distinct possibility would be trying to send color codes or
cursor movement codes not recognized by the terminal.
Vim running in a console (not gvim) will tell you all the terminal codes
it recognises (on input) or sends (on output) if you ask
:set termcap
Which codes your particular terminal actually sends or accepts is
usually somewhat harder to find out, and not in Vim's province.
Another possibility is the order of :set listchars=... and :set
encoding=... In order to get it right, you must have the following:
1) either (in Vim 7.2.102 or later) an UTF-8 BOM, or (even in earlier
versions) at the very top of the vimrc, a |:scriptencoding| statement
with the vimrc's 'fileencoding' (either utf-8 or latin1) as argument.
This will allow Vim to do the necessary conversions, if any.
2) set encoding=utf-8 fairly high in the vimrc
3) set lcs=<something> _after_ you set 'encoding'. The operand must
be coded in conformance with (1) above.
see
:help :scriptencoding
:help 'listchars'
Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
243. You unsuccessfully try to download a pizza from www.dominos.com.
Marc Abramowitz
It'd be interesting to see what vim is asking the terminal to do and then see if tmux perhaps is not doing what it's supposed to. This could lead to a bug fix in tmux if that's the culprit.
Tony Mechelynck
> Is there a way to get a dump of the codes that vim or an arbitrary program is sending to the terminal?
>
> It'd be interesting to see what vim is asking the terminal to do and then see if tmux perhaps is not doing what it's supposed to. This could lead to a bug fix in tmux if that's the culprit.
...Vim or an arbitrary program...? Maybe, but this is not a question
about Vim. Maybe someone other than me will be able to answer this
question on this list, or maybe you could get a better answer on some
list for your distro or on some "general" list for Unix-like software.
You might try to capture the stdin and stderr output, but beware that
Vim (and some other programs such as ls) will behave differently if
their output seems to be to something else than a terminal (for
instance, to a pipe or a disk).
Best regards,
Tony.
--
"I do not fear computers. I fear the lack of them."
-- Isaac Asimov
Gary Johnson
> Is there a way to get a dump of the codes that vim or an arbitrary
> program is sending to the terminal?
Yes. Run 'script' first, then run 'vim'. All the characters
exchanged between the terminal and 'vim' will be captured in the
file 'typescript. After exiting 'vim', exit 'script', then take a
look at the 'typescript' file.
Regards,
Gary
Marc Abramowitz
Bram Moolenaar
Marc Abramowitz wrote:
The "script" program can do that.
--
Not too long ago, unzipping in public was illegal...
Andy Wokula
> TALL KNIGHT: We shall say Ni! again to you if you do not appease us.
> ARTHUR: All right! What do you want?
> TALL KNIGHT: We want ... a shrubbery!
> "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
Vimmers shall say
:Ni!
to become tall knights. It works!
SCNR,
Andy