Ingo Karkat wrote:
> 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.
Thanks for locating and fixing the problem. I'll include the patch.
--
hundred-and-one symptoms of being an internet addict:
48. You get a tatoo that says "This body best viewed with Netscape 3.1 or
higher."
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
