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

Re: Does MacVim drop characters?

Expand Messages
  • 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 1 of 16 , Oct 1, 2008
      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 2 of 16 , Oct 1, 2008
        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 3 of 16 , Oct 1, 2008
          > 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 4 of 16 , Oct 2, 2008
            > 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 5 of 16 , Oct 2, 2008
              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 6 of 16 , Oct 2, 2008
                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 7 of 16 , Oct 2, 2008
                  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 8 of 16 , Oct 2, 2008
                    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.