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

Re: Does MacVim drop characters?

Expand Messages
  • 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 1 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 2 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 3 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 4 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.