On 09-Jun-08 22:50, Ingo Karkat wrote:
> On 09-Jun-08 21:04, Bram Moolenaar wrote:
>> Ingo Karkat wrote:
>>
>>> I'd like to report a bug that occurs when a very long ex command is
>>> entered, so that the GUI / console screen space isn't sufficient to
>>> display the complete command.
>>>
>>> I have an external VBScript that uses the VIM OLE SendKeys() function (or
>>> WshShell.SendKeys() as a fallback) to open a list of files in VIM via:
>>> :drop file1 file2 C:/Program\
>>> Files/this_is_a_very_very_very_long_filename If the list of files is
>>> longer than the available space for the ex command, the characters that
>>> didn't fit in are appended in reversed order: :args [file1] file2
>>> C:/Program\ Fiemanelif_gnol_yrev_yrev_yrev_a_si_siht/sel ^ BUG: reversed
>>> string!!! ^
>>>
>>> This happens: - both in GVIM and console VIM - on Windows and Linux -
>>> through OLE SendKeys(), VIM's feedkeys(<string>,'t'), or by manually
>>> typing the string - in VIM 7.1.311 until back to VIM 6.0 Probably, this
>>> is due to some bad pointer increment, which is hopefully easy to fix.
>>>
>>> Steps to reproduce: ------------------- vim -N -u NONE " Limit window
>>> size to minimize typing until overflow :-) :set columns=20 lines=4 :drop
>>> 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890
>>> 1234567890 1234567890 " Enlarge again to better see the output
>>> (optional). :set columns=80 :args [1234567890] 1234567890 1234567890
>>> 1234567890 1234567890 1234567890 12345670987654321 098 " Note the garbled
>>> strings at the end!
>>>
>>> You can also reproduce without resizing via feedkeys(): gvim -N -u NONE
>>> call feedkeys(':drop ', 't') | for i in range(1,500) | call
>>> feedkeys('1234567890 ', 't') | endfor | call feedkeys("\<CR>", 't') :args
>>>
>> I see the problem. I think the patch below fixes it properly.
>>
>>
>> *** ../vim-7.1.314/src/ex_getln.c Thu May 29 15:33:13 2008 ---
>> src/ex_getln.c Mon Jun 9 20:10:51 2008 *************** *** 2829,2838
>> ****
>> if (has_mbyte) correct_cmdspos(ccline.cmdpos, c); #endif ! /* Stop
>> cursor
>> at the end of the screen */ ! if (ccline.cmdspos + c >= m) !
>> break;
>> ! ccline.cmdspos += c; #ifdef FEAT_MBYTE if (has_mbyte) { ---
>> 2829,2839
>> ---- if (has_mbyte) correct_cmdspos(ccline.cmdpos, c); #endif !
>> /* Stop
>> cursor at the end of the screen, but do increment the ! *
>> insert
>> position, so that entering a very long command ! * works, even
>> though
>> you can't see it. */ ! if (ccline.cmdspos + c < m) !
>> ccline.cmdspos
>> += c; #ifdef FEAT_MBYTE if (has_mbyte) {
>>
>
> Not quite yet, it's now working in the Linux default "normal" version, but in
> the "big" version, your patch only changes the pattern of character
> scrambling; it's not plain string reversal anymore. Before the patch (using
> the 'feedkeys()' example): 1234567890 ... 1234567890 1234567890 0987654321
> 0987654321 0987654321 0987654321 After the patch: 1234567890 ... 1234567890
> 1234567890 89674523 190785634120 89674523 190785634120 89674523
>
> I'm just guessing, is there another wrong pointer increment somewhere else?
> I'm using console VIM "big version" on Linux; here's my :version output:
>
> VIM - Vi IMproved 7.1 (2007 May 12, compiled Jun 9 2008 22:11:08) Included
> patches: 1-311 Compiled by Ingo Karkat <[EMAIL PROTECTED]> Big version with
> GTK2
> 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_gui +diff +digraphs +dnd -ebcdic +emacs_tags +eval
> +ex_extra +extra_search +farsi +file_in_path +find_in_path +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_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_interact
> +xterm_clipboard -xterm_save system vimrc file: "$VIM/vimrc" user vimrc file:
> "$HOME/.vimrc" user exrc file: "$HOME/.exrc" system gvimrc file:
> "$VIM/gvimrc" user gvimrc file: "$HOME/.gvimrc" system menu file:
> "$VIMRUNTIME/menu.vim" fall-back for $VIM: "/usr/local/share/vim"
> Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK
> -I/usr/include/g tk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0
> -I/usr/include/cairo -I /usr/include/pango-1.0 -I/usr/include/glib-2.0
> -I/usr/lib/glib-2.0/include -I/us r/include/freetype2 -I/usr/include/libpng12
> -g -O2 Linking: gcc -L/usr/local/lib -o vim -lgtk-x11-2.0 -lgdk-x11-2.0
> -latk-1.0 - lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo
> -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lXt -lncurses -lacl -lgpm
>
> -- regards, ingo
>
> /^-- Ingo Karkat -- /^-- /^-- /^-- /^-- /^-- /^-- http://ingo-karkat.de/ --
>
> The goal of science is to build better mousetraps. The goal of nature is to
> build better mice.
Hi Bram,
Your patch from a week ago fixed the reversed string in a long ex command only
for --with-features=normal. I located the problem that still caused scrambling
of characters in compiles --with-features=big.
I've narrowed down the bug to -DFEAT_ARABIC, which is set in the big, but not in
the normal version. Inside getcmdline(firstc, count, indent), this fragment:
#ifdef FEAT_RIGHTLEFT
if (cmdmsg_rl
# ifdef FEAT_ARABIC
|| (p_arshape && !p_tbidi && enc_utf8)
# endif
)
/* Always redraw the whole command line to fix shaping and
* right-left typing. Not efficient, but it works. */
redrawcmd();
#endif
calls redrawcmd(), which, if the cmdline doesn't fit, puts the cursor on the
last visible char. However, it also decremented the current cursor position in
that case, which caused the scrambling. I believe the cursor position inside the
cmdline should not be modified in that case.
The patch below contains the complete fix; I've tested on Linux/x86, both
console and GVIM. I haven't tested rightleft mode or Arabic text entry.
-- regards, ingo
Index: src/ex_getln.c
===================================================================
*** src/ex_getln.c (revision 1049)
--- src/ex_getln.c (working copy)
***************
*** 2056,2062 ****
/* If the cmdline doesn't fit, put cursor on last visible char. */
if ((ccline.cmdspos += c) >= m)
{
- ccline.cmdpos = i - 1;
ccline.cmdspos -= c;
break;
}
--- 2056,2061 ----
***************
*** 2829,2838 ****
if (has_mbyte)
correct_cmdspos(ccline.cmdpos, c);
#endif
! /* Stop cursor at the end of the screen */
! if (ccline.cmdspos + c >= m)
! break;
! ccline.cmdspos += c;
#ifdef FEAT_MBYTE
if (has_mbyte)
{
--- 2828,2838 ----
if (has_mbyte)
correct_cmdspos(ccline.cmdpos, c);
#endif
! /* Stop cursor at the end of the screen, but do increment the
! * insert position, so that entering a very long command
! * works, even though you can't see it. */
! if (ccline.cmdspos + c < m)
! ccline.cmdspos += c;
#ifdef FEAT_MBYTE
if (has_mbyte)
{
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
