package vim
tag 292397 + upstream
tag 292397 + patch
thansk
Hi!
I've done some more debugging on this problem, and it seems only a few
of the vim variants are affected. Specifically, I can reprocude the
problem using vim.gnome, vim.python and vim.perl, but vim.basic,
vim.gtk, vim.tiny, vim.lesstif, vim.ruby, vi.tcl and vim.full work fine.
Also, I've build a version of vim.perl with -ggdb3, and can reproduce
the problem there. GDB gives the following backtrace after the freeze:
| (gdb) bt
| #0 0xffffe410 in __kernel_vsyscall ()
| #1 0xb77fed6d in ___newselect_nocancel () from /lib/tls/i686/cmov/libc.so.6
| #2 0x0815887b in RealWaitForChar (fd=0, msec=100, check_for_gpm=0xbfcd399c)
at os_unix.c:4743
| #3 0x081585c1 in WaitForChar (msec=100) at os_unix.c:4445
| #4 0x08154b75 in mch_inchar (buf=0xbfcd3a4a "", maxlen=46, wtime=100,
tb_change_cnt=0) at os_unix.c:328
| #5 0x081b950f in ui_inchar (buf=0xbfcd3a4a "", maxlen=46, wtime=100,
tb_change_cnt=0) at ui.c:189
| #6 0x081185dd in get_keystroke () at misc1.c:3025
| #7 0x08111f63 in do_dialog (type=2, title=0x81fb014 "VIM - ATTENTION",
message=0x82fa060 "Swap file \"/tmp//%tmp%test.swp\" already exists!",
buttons=0x81faf88 "&Open Read-Only\n&Edit anyway\n&Recover\n&Quit\n&Abort",
dfltbutton=1, textfield=0x0) at message.c:3298
| #8 0x0810971d in findswapname (buf=0x8234428, dirp=0xbfcd404c,
old_fname=0x0) at memline.c:4107
| #9 0x081039a2 in ml_open_file (buf=0x8234428) at memline.c:552
| #10 0x08103ac4 in check_need_swap (newfile=1) at memline.c:604
| #11 0x080d27d0 in readfile (fname=0x8235848 "/tmp/test", sfname=0x8235848
"/tmp/test", from=0, lines_to_skip=0, lines_to_read=2147483647, eap=0x0,
flags=1) at fileio.c:642
| #12 0x0806c4a2 in open_buffer (read_stdin=0, eap=0x0) at buffer.c:130
| #13 0x080f770a in create_windows (parmp=0xbfcd43f0) at main.c:2378
| #14 0x080f5589 in main (argc=2, argv=0xbfcd4534) at main.c:794
If I set a breakpoint on line 3026 of misc1.c (just after the
ui_inchar() call), I can verify that indeed a special key code is
returned (i.e. the cursor I pressed). Specifically, the key code
returned is 0x80 0x8a 0x95 ("\eku", which I guess means the uparrow).
However, this key is not handled at all: in the FEAT_MBYTE ifdef on
line 3084, the "continue" is called, and the loop progresses to the next
iteration, after which the key is never returned anymore by
get_keystroke().
So, the problem seems to be that the special sequences that are
generated by the cursor keys are mistaken for an incomplete multibyte
sequence; the check for such a special sequence is only done in
do_diaglog(), after get_keystroke() has returned.
The following patch solves this, and works fine here. Please include it
in the debian packages and also send it upstream.
--- vim/src/misc1.eerst 2006-04-13 13:45:37.000000000 +0200
+++ vim/src/misc1.c 2006-04-13 13:48:10.000000000 +0200
@@ -3082,7 +3082,9 @@
}
}
#ifdef FEAT_MBYTE
- if (has_mbyte)
+ /* if n<0, this is a special key (eg cursor) which should
+ * not be mistaken for an incomplete multibyte sequence */
+ if (has_mbyte && n>=0)
{
if (MB_BYTE2LEN(n) > len)
continue; /* more bytes to get */
Happy Vimming!
Bas.
PS: this was all tested using the 6.4+7.0c05-1 versions from
experimental.
--
Kind regards,
+--------------------------------------------------------------------+
| Bas Zoetekouw | GPG key: 0644fab7 |
|----------------------------| Fingerprint: c1f5 f24c d514 3fec 8bf6 |
| [EMAIL PROTECTED], [EMAIL PROTECTED] | a2b1 2bae e41f 0644 fab7 |
+--------------------------------------------------------------------+
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
