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

Does MacVim drop characters?

Expand Messages
  • Nico Weber
    Hi, 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
    Message 1 of 16 , Sep 30, 2008
    • 0 Attachment
      Hi,

      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?

      Nico

      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_mac" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • Matt Tolton
      I have noticed this, too. It is especially annoying when I m editing a file on NFS and vim is doing one of its frequent stat() operations on the file (which
      Message 2 of 16 , Sep 30, 2008
      • 0 Attachment
        I have noticed this, too. It is especially annoying when I'm editing
        a file on NFS and vim is doing one of its frequent stat() operations
        on the file (which tends to cause a slight pause). It drops
        characters that I type. :(

        On Tue, Sep 30, 2008 at 10:13 PM, Nico Weber <nicolasweber@...> wrote:
        >
        > Hi,
        >
        > 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?
        >
        > Nico
        >
        > >
        >

        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_mac" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • Jonathon Mah
        ... Not knowing anything about it, I d venture a guess it might be e55c4
        Message 3 of 16 , Oct 1, 2008
        • 0 Attachment
          On 2008-10-01, at 14:43, Nico Weber wrote:

          > Did my typing skills get worse, or does MacVim drop keystrokes since
          > snapshot 35?


          Not knowing anything about it, I'd venture a guess it might be e55c4

          <http://repo.or.cz/w/MacVim.git?a=commitdiff;h=e55c4ffec3bed90e27639b5e9943386621b63a59
          >



          Jonathon Mah
          me@...



          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_mac" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---
        • Ted Pavlic
          I have noticed the same problem. It is something specific to snapshot 35. Things have gotten WAY worse since I ve updated. --Ted ... -- Ted Pavlic
          Message 4 of 16 , Oct 1, 2008
          • 0 Attachment
            I have noticed the same problem. It is something specific to snapshot
            35. Things have gotten WAY worse since I've updated.

            --Ted

            Nico Weber wrote:
            >
            > Hi,
            >
            > 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?
            >
            > Nico
            >
            > >
            >

            --
            Ted Pavlic <ted@...>

            --~--~---------~--~----~------------~-------~--~----~
            You received this message from the "vim_mac" maillist.
            For more information, visit http://www.vim.org/maillist.php
            -~----------~----~----~----~------~----~------~--~---
          • Ted Pavlic
            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
            Message 5 of 16 , Oct 1, 2008
            • 0 Attachment
              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.

              --Ted

              Ted Pavlic wrote:
              > I have noticed the same problem. It is something specific to snapshot
              > 35. Things have gotten WAY worse since I've updated.
              >
              > --Ted
              >
              > Nico Weber wrote:
              >> Hi,
              >>
              >> 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?
              >>
              >> Nico
              >>
              >> >>
              >>
              >

              --
              Ted Pavlic <ted@...>

              --~--~---------~--~----~------------~-------~--~----~
              You received this message from the "vim_mac" maillist.
              For more information, visit http://www.vim.org/maillist.php
              -~----------~----~----~----~------~----~------~--~---
            • Ted Pavlic
              Going back to MacVim-7.2-stable-1.2 fixes the problem. /Of course becomes /Of course . --Ted ... -- Ted Pavlic
              Message 6 of 16 , Oct 1, 2008
              • 0 Attachment
                Going back to MacVim-7.2-stable-1.2 fixes the problem. "/Of course"
                becomes "/Of course".

                --Ted

                Ted Pavlic wrote:
                >
                > 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.
                >
                > --Ted
                >
                > Ted Pavlic wrote:
                >> I have noticed the same problem. It is something specific to snapshot
                >> 35. Things have gotten WAY worse since I've updated.
                >>
                >> --Ted
                >>
                >> Nico Weber wrote:
                >>> Hi,
                >>>
                >>> 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?
                >>>
                >>> Nico
                >>>
                >

                --
                Ted Pavlic <ted@...>

                --~--~---------~--~----~------------~-------~--~----~
                You received this message from the "vim_mac" maillist.
                For more information, visit http://www.vim.org/maillist.php
                -~----------~----~----~----~------~----~------~--~---
              • björn
                ... 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
                Message 7 of 16 , Oct 1, 2008
                • 0 Attachment
                  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.

                  Björn

                  --~--~---------~--~----~------------~-------~--~----~
                  You received this message from the "vim_mac" maillist.
                  For more information, visit http://www.vim.org/maillist.php
                  -~----------~----~----~----~------~----~------~--~---
                • Jonathon Mah
                  Hi Björn, ... That sounds like you d be implementing that behavior on the back-end. How would that handle the case of repeating a key, and then pressing
                  Message 8 of 16 , Oct 1, 2008
                  • 0 Attachment
                    Hi Björn,

                    On 2008-10-02, at 01:16, björn wrote:

                    > 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.


                    That sounds like you'd be implementing that behavior on the back-end.
                    How would that handle the case of repeating a key, and then pressing
                    another key?

                    I think of keyboard repeat as a "non-deterministic" thing; that is, it
                    requires feedback (audio/visual) to be useful. So any time the screen
                    gets out of sync with keyboard repeat is a bad thing. I'd recommend
                    having the back-end process check in with the front-end when it's done
                    processing its command queue, and then have the front-end implement
                    keyboard repeat internally.

                    The back-end would need to send back the last key it processed,
                    otherwise there could be a race condition.

                    That is,
                    1. Front-end gets key presses, "hi.<esc>j" ('j' is held down by the
                    user). Saves time of last key press.
                    2. Front-end posts those keys to the back-end ('j' only once)
                    3. Back-end processes queue, sends back EmptiedInputQueueEndingWith('j')
                    4. Front-end gets message, sees that 'j' is still held down. If time
                    of last key press < repeat interval, then start a timer waiting until
                    it is.
                    5. Now it's past the key repeat interval. If the key is still down,
                    send one 'j' to the back-end, sets "repeating" status.
                    6. Back-end processes key, sends back EmptiedInputQueueEndingWith
                    7. Front-end gets message. If time of last key message < key repeat
                    rate, start a timer. Loop to 5.

                    It's fairly convoluted, but it seems like the most desirable behavior
                    to me. You'd have to be careful doing repeat with modifiers, too. What
                    do you think?


                    Key repeat rates (in ticks, 1/60 sec):
                    [[NSUserDefaults standardUserDefaults] integerForKey:@"KeyRepeat"]
                    [[NSUserDefaults standardUserDefaults]
                    integerForKey:@"InitialKeyRepeat"]

                    Is an event a key repeat? -[NSEvent isARepeat]



                    Jonathon Mah
                    me@...



                    --~--~---------~--~----~------------~-------~--~----~
                    You received this message from the "vim_mac" maillist.
                    For more information, visit http://www.vim.org/maillist.php
                    -~----------~----~----~----~------~----~------~--~---
                  • björn
                    ... I don t see the problem. If a key is pressed while another is repeating, the repeating key will stop repeating. Did I miss something? ... It does seem
                    Message 9 of 16 , Oct 1, 2008
                    • 0 Attachment
                      2008/10/1 Jonathon Mah <me@...>:
                      >
                      >> 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.
                      >
                      > That sounds like you'd be implementing that behavior on the back-end.
                      > How would that handle the case of repeating a key, and then pressing
                      > another key?

                      I don't see the problem. If a key is pressed while another is
                      repeating, the repeating key will stop repeating. Did I miss
                      something?

                      > I think of keyboard repeat as a "non-deterministic" thing; that is, it
                      > requires feedback (audio/visual) to be useful. So any time the screen
                      > gets out of sync with keyboard repeat is a bad thing. I'd recommend
                      > having the back-end process check in with the front-end when it's done
                      > processing its command queue, and then have the front-end implement
                      > keyboard repeat internally.
                      >
                      > The back-end would need to send back the last key it processed,
                      > otherwise there could be a race condition.
                      >
                      > That is,
                      > 1. Front-end gets key presses, "hi.<esc>j" ('j' is held down by the
                      > user). Saves time of last key press.
                      > 2. Front-end posts those keys to the back-end ('j' only once)
                      > 3. Back-end processes queue, sends back EmptiedInputQueueEndingWith('j')
                      > 4. Front-end gets message, sees that 'j' is still held down. If time
                      > of last key press < repeat interval, then start a timer waiting until
                      > it is.
                      > 5. Now it's past the key repeat interval. If the key is still down,
                      > send one 'j' to the back-end, sets "repeating" status.
                      > 6. Back-end processes key, sends back EmptiedInputQueueEndingWith
                      > 7. Front-end gets message. If time of last key message < key repeat
                      > rate, start a timer. Loop to 5.
                      >
                      > It's fairly convoluted, but it seems like the most desirable behavior
                      > to me. You'd have to be careful doing repeat with modifiers, too. What
                      > do you think?

                      It does seem overly complicated (perhaps because I didn't fully
                      understand it yet) and I think the patch I wrote fixes the problem
                      with a lot less work. Also, it doesn't seem to work well with the
                      Cocoa input method where you don't test to see if a key is held,
                      instead it sends events when a key is pressed and released. If my
                      patch doesn't work I'll think some more about what you suggest, but
                      for now I'd like to wait and see what the reaction to the patch is. I
                      appreciate the input though!

                      Björn

                      --~--~---------~--~----~------------~-------~--~----~
                      You received this message from the "vim_mac" maillist.
                      For more information, visit http://www.vim.org/maillist.php
                      -~----------~----~----~----~------~----~------~--~---
                    • Jonathon Mah
                      ... I haven t looked at your patch yet, but the situation I was thinking about is when a key is repeated (so there are keypresses in the queue that haven t
                      Message 10 of 16 , Oct 1, 2008
                      • 0 Attachment
                        On 2008-10-02, at 07:35, björn wrote:

                        > 2008/10/1 Jonathon Mah <me@...>:
                        >>
                        >>> 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.
                        >>
                        >> That sounds like you'd be implementing that behavior on the back-end.
                        >> How would that handle the case of repeating a key, and then pressing
                        >> another key?
                        >
                        > I don't see the problem. If a key is pressed while another is
                        > repeating, the repeating key will stop repeating. Did I miss
                        > something?


                        I haven't looked at your patch yet, but the situation I was thinking
                        about is when a key is repeated (so there are keypresses in the queue
                        that haven't been drawn yet), and a different key is pressed. The
                        first key is no longer repeating, but its past repeats could still be
                        queued. Think holding down 'j', so a lot of scroll events are queued,
                        then hitting 'o'. When the 'o' event comes in, should the queued-but-
                        not-drawn scroll commands be discarded?



                        Jonathon Mah
                        me@...



                        --~--~---------~--~----~------------~-------~--~----~
                        You received this message from the "vim_mac" maillist.
                        For more information, visit http://www.vim.org/maillist.php
                        -~----------~----~----~----~------~----~------~--~---
                      • Matt Tolton
                        ... Seems like it would be hard to determine which keypresses indicate scroll events and which do not. I could be mapping just about any key in vim to do the
                        Message 11 of 16 , Oct 1, 2008
                        • 0 Attachment
                          > I haven't looked at your patch yet, but the situation I was thinking
                          > about is when a key is repeated (so there are keypresses in the queue
                          > that haven't been drawn yet), and a different key is pressed. The
                          > first key is no longer repeating, but its past repeats could still be
                          > queued. Think holding down 'j', so a lot of scroll events are queued,
                          > then hitting 'o'. When the 'o' event comes in, should the queued-but-
                          > not-drawn scroll commands be discarded?

                          Seems like it would be hard to determine which keypresses indicate
                          scroll events and which do not. I could be mapping just about any key
                          in vim to do the same thing as j.

                          --~--~---------~--~----~------------~-------~--~----~
                          You received this message from the "vim_mac" maillist.
                          For more information, visit http://www.vim.org/maillist.php
                          -~----------~----~----~----~------~----~------~--~---
                        • Matt Tolton
                          ... Scratch that...it doesn t matter. You re talking about doing this for any repeating key, which makes sense. Sorry.
                          Message 12 of 16 , Oct 2, 2008
                          • 0 Attachment
                            > Seems like it would be hard to determine which keypresses indicate
                            > scroll events and which do not. I could be mapping just about any key
                            > in vim to do the same thing as j.

                            Scratch that...it doesn't matter. You're talking about doing this for
                            any repeating key, which makes sense. Sorry.

                            --~--~---------~--~----~------------~-------~--~----~
                            You received this message from the "vim_mac" maillist.
                            For more information, visit http://www.vim.org/maillist.php
                            -~----------~----~----~----~------~----~------~--~---
                          • Steve Huff
                            ... it s all relative, i guess... i see this problem frequently on a 1.5GHz PPC mini at the office and much less frequently (but i still see it!) on a dual
                            Message 13 of 16 , Oct 2, 2008
                            • 0 Attachment
                              On Oct 1, 2008, at 11:46 AM, björn wrote:

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

                              it's all relative, i guess... i see this problem frequently on a
                              1.5GHz PPC mini at the office and much less frequently (but i still
                              see it!) on a dual 2.16GHz MacBook Pro at home. we can't all have
                              fancy MacBook Airs :)

                              -steve


                              --~--~---------~--~----~------------~-------~--~----~
                              You received this message from the "vim_mac" maillist.
                              For more information, visit http://www.vim.org/maillist.php
                              -~----------~----~----~----~------~----~------~--~---
                            • björn
                              ... The way it works now is: 1. input arrives 2. is it a repeat? 2a. yes - queue it unless there already is input on the queue (in which case it is silently
                              Message 14 of 16 , Oct 2, 2008
                              • 0 Attachment
                                2008/10/2 Jonathon Mah <me@...>:
                                >>>
                                >>> That sounds like you'd be implementing that behavior on the back-end.
                                >>> How would that handle the case of repeating a key, and then pressing
                                >>> another key?
                                >>
                                >> I don't see the problem. If a key is pressed while another is
                                >> repeating, the repeating key will stop repeating. Did I miss
                                >> something?
                                >
                                > I haven't looked at your patch yet, but the situation I was thinking
                                > about is when a key is repeated (so there are keypresses in the queue
                                > that haven't been drawn yet), and a different key is pressed. The
                                > first key is no longer repeating, but its past repeats could still be
                                > queued. Think holding down 'j', so a lot of scroll events are queued,
                                > then hitting 'o'. When the 'o' event comes in, should the queued-but-
                                > not-drawn scroll commands be discarded?

                                The way it works now is:

                                1. input arrives
                                2. is it a repeat?
                                2a. yes - queue it unless there already is input on the queue (in
                                which case it is silently dropped)
                                2b. no - just add it to the queue

                                The idea is that the user won't notice if a repeated key is dropped
                                but a typed key will most certainly be noticed. Also, the input
                                handling routine does not distinguish between key input representing
                                "scrolling" and "typing" (this would be a complete mess).

                                Hence there will never be more than one repeated key on the input
                                queue at a time so the scenario you outline cannot happen.

                                Björn

                                --~--~---------~--~----~------------~-------~--~----~
                                You received this message from the "vim_mac" maillist.
                                For more information, visit http://www.vim.org/maillist.php
                                -~----------~----~----~----~------~----~------~--~---
                              • Frank Hellenkamp
                                Hi, ... Does repeat mean keys, that are coming from auto-repeat, or also keys like when I press two or three times m ? When it is the second one, it should
                                Message 15 of 16 , Oct 2, 2008
                                • 0 Attachment
                                  Hi,

                                  >>>> That sounds like you'd be implementing that behavior on the back-end.
                                  >>>> How would that handle the case of repeating a key, and then pressing
                                  >>>> another key?
                                  >>> I don't see the problem. If a key is pressed while another is
                                  >>> repeating, the repeating key will stop repeating. Did I miss
                                  >>> something?
                                  >> I haven't looked at your patch yet, but the situation I was thinking
                                  >> about is when a key is repeated (so there are keypresses in the queue
                                  >> that haven't been drawn yet), and a different key is pressed. The
                                  >> first key is no longer repeating, but its past repeats could still be
                                  >> queued. Think holding down 'j', so a lot of scroll events are queued,
                                  >> then hitting 'o'. When the 'o' event comes in, should the queued-but-
                                  >> not-drawn scroll commands be discarded?
                                  >
                                  > The way it works now is:
                                  >
                                  > 1. input arrives
                                  > 2. is it a repeat?
                                  > 2a. yes - queue it unless there already is input on the queue (in
                                  > which case it is silently dropped)
                                  > 2b. no - just add it to the queue

                                  Does "repeat" mean keys, that are coming from auto-repeat, or also keys
                                  like when I press two or three times "m"?

                                  When it is the second one, it should probably drop from the third key
                                  on, not from the second. (Like in "will", "miss", "kommen", "pressed" etc.)


                                  best regards,

                                  Frank

                                  --
                                  frank hellenkamp | interface designer
                                  jonas.info@... | mail
                                  +49.30.49 78 20 70 | tel
                                  +49.173.70 55 781 | mbl
                                  +49.1805.4002.243 912 | fax
                                • björn
                                  ... By repeat I mean auto-repeat , as in hold down a key and the OS will repeat it for you . If you hit m 20 times in a row, then they are all
                                  Message 16 of 16 , Oct 2, 2008
                                  • 0 Attachment
                                    2008/10/2 Frank Hellenkamp <jonas.info@...>:
                                    >>
                                    >> The way it works now is:
                                    >>
                                    >> 1. input arrives
                                    >> 2. is it a repeat?
                                    >> 2a. yes - queue it unless there already is input on the queue (in
                                    >> which case it is silently dropped)
                                    >> 2b. no - just add it to the queue
                                    >
                                    > Does "repeat" mean keys, that are coming from auto-repeat, or also keys
                                    > like when I press two or three times "m"?
                                    >
                                    > When it is the second one, it should probably drop from the third key
                                    > on, not from the second. (Like in "will", "miss", "kommen", "pressed" etc.)

                                    By "repeat" I mean "auto-repeat", as in "hold down a key and the OS
                                    will repeat it for you". If you hit "m" 20 times in a row, then they
                                    are all processed. If you hold down "m" for 20 seconds, nobody knows
                                    how many "m" will be processed.

                                    I think it would be unreasonable to check the input and drop a key if
                                    it is appears three times or more in a row.

                                    Björn

                                    --~--~---------~--~----~------------~-------~--~----~
                                    You received this message from the "vim_mac" maillist.
                                    For more information, visit http://www.vim.org/maillist.php
                                    -~----------~----~----~----~------~----~------~--~---
                                  Your message has been successfully submitted and would be delivered to recipients shortly.