Loading ...
Sorry, an error occurred while loading the content.

9142Re: Does MacVim drop characters?

Expand Messages
  • björn
    Oct 1, 2008
      2008/10/1 Ted Pavlic <ted@...>:
      >>> 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.

      Ouch, that is pretty bad. I guess your computer is a lot slower than mine.

      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
    • Show all 16 messages in this topic