Vim hangs on pasting a large amount into command line
John Beckett
(example: type ':echo ' then Ctrl-R a to paste register a).
If I accidentally paste a large amount (kilobytes), I have to
wait a very long time (several minutes) while Vim struggles to
handle the text. Pressing Ctrl-C has no discernible effect.
Last July, someone complained about this at vim_mac:
http://groups.google.com/group/vim_mac/browse_thread/thread/7b520681cfc3a464
I see that cmdline_paste() (in src/ops.c) uses ui_breakcheck()
in anticipation of this problem, but it does not seem to work on
console or gui Vim on Linux or Windows (Vim 7.3e).
Does anyone have evidence that Ctrl-C will interrupt a command
line paste on some system?
John
John Beckett
> (example: type ':echo ' then Ctrl-R a to paste register a).
>
> If I accidentally paste a large amount (kilobytes), I have to
> wait a very long time (several minutes) while Vim struggles
> to handle the text. Pressing Ctrl-C has no discernible effect.
Some investigating shows that removing the following call to
redrawcmd() fixes the problem (this is not a solution, just
a preliminary observation):
In function getcmdline() (file ex_getln.c line 1840) we find:
/* Always redraw the whole command line to fix shaping and
* right-left typing. Not efficient, but it works. */
redrawcmd();
Removing that redrawcmd() makes accidental pastes of 8000 bytes
into the command line occur in a second or so. With an unpatched
Vim, that same paste sometimes seem to complete in a minute, and
sometimes seems to take forever (I killed it after several
minutes).
I have set encoding=utf-8, and I think you need that for the
above redrawcmd() to be executed.
While I should not be pasting junk into the command line, Vim
should not effectively hang if I accidentally do.
John
Andy Block
>> Sometimes I paste some text into the Vim command line
>> (example: type ':echo ' then Ctrl-R a to paste register a).
>>
>> If I accidentally paste a large amount (kilobytes), I have to
>> wait a very long time (several minutes) while Vim struggles
>> to handle the text. Pressing Ctrl-C has no discernible effect.
>
> Some investigating shows that removing the following call to
> redrawcmd() fixes the problem (this is not a solution, just
> a preliminary observation):
Are you by any chance using MacVim? I had this problem with MacVim and raised it in the MacVim list. Here is how that conversation went:
> On Jul 4, 2010, at 3:46 PM, björn wrote:
>
>> On 4 July 2010 13:13, Andy Block wrote:
>>> On Jul 4, 2010, at 12:58 PM, björn wrote:
>>>
>>>> On 3 July 2010 21:25, Andy wrote:
>>>>>
>>>>> I have one major annoyance with MacVim, which I'm surprised I can't
>>>>> find anyone else mentioning. Specifically, on a semi-regular basis, I
>>>>> copy a large amount of text from, e.g., a terminal session, switch to
>>>>> vim, paste it, and - bang! I discover I was in command line mode and
>>>>> as a result I am in for a long wait.
>>>>
>>>> Ouch! I was not aware of this problem. Fortunately there is an easy
>>>> fix: use Cmd-. instead of Ctrl-C to interrupt.
>>>
>>> Thanks for you quick response, and suggested workaround. However, Cmd-. also does not appear to interrupt for me. Did you confirm that it worked for you? Would this behaviour depend on any configuration, or the setting of some option? Thanks again,
>>
>> Yes, I did confirm before posting. Which version of MacVim are you
>> using? You should be using a snapshot, or the 7.3a BETA [1] -- the
>> stable build is probably too old. No configuration option will affect
>> Cmd-. (it is hardwired).
>
> Ah - that'd be it then. I should have mentioned before that I am indeed using the last stable build (7.2). I'll have a go with something more recent then. Thanks again, regards,
>
> Andy
Hope that is helpful! Regards,
Andy
Ingo Karkat
There's no need to modify the source code to avoid the redraw; just turn off
Arabic shaping. There was a discussion about this on this list two years ago (I
was involved, that's why I remember ;-):
http://tech.groups.yahoo.com/group/vimdev/message/51944
http://tech.groups.yahoo.com/group/vimdev/message/51952
Because I don't need Arabic shaping, I have this in my .vimrc:
" Avoid command-line redraw on every entered character by turning off Arabic
" shaping (which is implemented poorly).
if has('arabic')
set noarabicshape
endif
Of course, back then we had already reached the conclusion that to fix this
properly, the implementation should be improved. Seems that nobody has taken up
that challenge yet.
-- regards, ingo
Bram Moolenaar
John Beckett wrote:
The intention of this call to redrawcmd() was to only do this when the
text has characters that are difficult to get right, such as Hebrew and
Arabic. Unfortunately the option settings are now the default.
I see two possible solutions:
1. Don't redraw when there is text pending, using char_avail(). Need to
set a flag then and redraw later, before waiting for any character to
be typed.
2. Don't redraw when the command line contains only "normal" characters.
Either ASCII or perhaps only redraw when there are composing characters.
Checking for Arabic is probably a bit too specific.
--
Those who live by the sword get shot by those who don't.
/// Bram Moolenaar -- Br...@Moolenaar.net -- 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 ///
John Beckett
>> In function getcmdline() (file ex_getln.c line 1840) we find:
>> /* Always redraw the whole command line to fix shaping and
>> * right-left typing. Not efficient, but it works. */
>> redrawcmd();
>>
>> Removing that redrawcmd() makes accidental pastes of 8000
>> bytes into the command line occur in a second or so.
> The intention of this call to redrawcmd() was to only do this
> when the text has characters that are difficult to get right,
> such as Hebrew and Arabic. Unfortunately the option settings
> are now the default.
>
> I see two possible solutions:
> 1. Don't redraw when there is text pending, using
> char_avail(). Need to set a flag then and redraw later,
> before waiting for any character to be typed.
> 2. Don't redraw when the command line contains only "normal"
> characters.
> Either ASCII or perhaps only redraw when there are
> composing characters. Checking for Arabic is probably a bit
> too specific.
While it would best to eliminate the redundant redraws
altogether (and I'll perhaps have a chance to look at that after
7.3 is released), I was wondering what happens once echoing of
the command fills the screen. There seems to be a flag which
tells Vim to only redraw the last line once the screen fills,
and I thought that at least the paste problem might be avoided
if that flag were used to not redraw once the screen fills. The
redraw fails anyway; the last line is garbled, which you can see
if you run the following code to generate some consistent text,
then copy and paste that text into the command line (caution:
you may have to kill Vim to recover).
:new
:for i in range(1, 500)
: call append(line('$'), printf('%04d-abcdefghijklmn', i))
:endfor
The stress of all those redraws when pasting 10k characters
sometimes makes Vim crash. If Dominique notices this, perhaps he
could use some valgrind magic to see if something obvious needs
to be fixed.
John
John Beckett
> There's no need to modify the source code to avoid the
> redraw; just turn off Arabic shaping. There was a discussion
> about this on this list two years ago (I was involved, that's
> why I remember ;-):
> http://tech.groups.yahoo.com/group/vimdev/message/51944
> http://tech.groups.yahoo.com/group/vimdev/message/51952
>
> Because I don't need Arabic shaping, I have this in my .vimrc:
>
> " Avoid command-line redraw on every entered character by
> turning off Arabic
> " shaping (which is implemented poorly).
> if has('arabic')
> set noarabicshape
> endif
Thanks, I'll use that. Of course I was only removing stuff from
the source while buried in a debugger trying to work out where
the code got lost when pasting into the command line.
John
John Beckett
> Are you by any chance using MacVim? I had this problem with
> MacVim and raised it in the MacVim list.
No, but I mentioned your post earlier, see:
http://groups.google.com/group/vim_dev/browse_thread/thread/40e590a3b0ca1b43
I had experienced this frustration a couple of times before
seeing your thread in mac_vim, and it was that with the
impending release of Vim 7.3 which made me want to investigate.
Notice the workaround in this thread posted by Ingo Karkat.
John
Tony Mechelynck
[...]
> While it would best to eliminate the redundant redraws
> altogether (and I'll perhaps have a chance to look at that after
> 7.3 is released), I was wondering what happens once echoing of
> the command fills the screen. There seems to be a flag which
> tells Vim to only redraw the last line once the screen fills,
'lazyredraw' maybe?
> and I thought that at least the paste problem might be avoided
> if that flag were used to not redraw once the screen fills. The
> redraw fails anyway; the last line is garbled, which you can see
> if you run the following code to generate some consistent text,
> then copy and paste that text into the command line (caution:
> you may have to kill Vim to recover).
>
> :new
> :for i in range(1, 500)
> : call append(line('$'), printf('%04d-abcdefghijklmn', i))
> :endfor
>
> The stress of all those redraws when pasting 10k characters
> sometimes makes Vim crash. If Dominique notices this, perhaps he
> could use some valgrind magic to see if something obvious needs
> to be fixed.
>
> John
>
Best regards,
Tony.
--
I for one cannot protest the recent M.T.A. fare hike and the
accompanying promises that this would in no way improve service. For
the transit system, as it now operates, has hidden advantages that
can't be measured in monetary terms.
Personally, I feel that it is well worth 75 cents or even $1 to have
that unimpeachable excuse whenever I am late to anything: "I came by
subway." Those four words have such magic in them that if Godot should
someday show up and mumble them, any audience would instantly
understand his long delay.