9142Re: Does MacVim drop characters?
- Oct 1, 20082008/10/1 Ted Pavlic <ted@...>:
>Ouch, that is pretty bad. I guess your computer is a lot slower than mine.
>>> when I'm editing a large markdown file, MacVim gets really sluggish at
>>> times (that's the fault of my markdown syntax file, ordinary vim also
>>> gets really sluggish). Sometimes, I type faster than the screen
>>> updates for a few seconds and the characters on screen only catch up
>>> after I make a typing pause.
>>> With MacVim Snapshot 35, I have the impression that severals of the
>>> keys I type during the time MacVim catches up with the input simply
>>> get dropped. For example, if I type in
>>> "Let's see if MacVim drops characters if I type fast."
>>> I actually get
>>> "Let's see if MacVim drops characters if I typ fst."
>>> Did my typing skills get worse, or does MacVim drop keystrokes since
>>> snapshot 35?
> Additionally, I notice that the problem...
> *) is worse in insert mode when my new text is "pushing" characters to
> the right of it. That is, it's not as bad when there's empty line in
> front of the cursor.
> *) also occurs in search mode. That is, typing "/Of course" in command
> mode turns into "/Ofcse".
> Again, this is a problem I only notice with Snapshot 35. I'm thinking of
> going back to the last release I had to see if that gets rid of the
> problem. I'm pretty sure it will.
So the problem is this: Previously the backend would process one
event at a time and the DO system kept a queue. Unless a _lot_ of
input was generated rapidly this meant no input would be dropped.
However, if too much arrived at once MacVim would beach ball -- this
has been a problem in many instances in the past.
Now, this changed with snap 35 so that all events are popped off the
DO queue at once and kept in a queue in the backend. This cures the
beach ball problem, but one problem still remained: holding "j" to
scroll and then letting go would not cause the scrolling to stop
immediately -- instead it would keep scrolling for a while as all the
input was processed. Also, when scrolling "slow" files (e.g.
Ruby+cursorline+Relative Number plugin) several "j" events would be
processed before the screen updating, resulting in the scrolling
"jumping" in a visually unpleasant way. To cure this I simply decided
to keep the last input received and drop the rest and that works
pretty well on my computer. But, obviously this is causing problems
as described above (I never thought it would be that bad).
So, for a solution. There are two conflicting goals:
1. When typing, don't drop any input
2. Avoid the scrolling problem above (and similar problems that I
can't think of right now)
The only thing I can think of right now that may work is to drop
keyboard input if it comes from a repeated press (i.e. holding down
"j"), but not when it represent a single key press. I'm going to try
that now and see how it goes. Other ideas are, as always, welcome.
You received this message from the "vim_mac" maillist.
For more information, visit http://www.vim.org/maillist.php
- << Previous post in topic Next post in topic >>