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

More Std vs Pro Behavior Differences

Expand Messages
  • Art Kocsis
    NT Pro is a bit schizophrenic. It can t make up its mind whether or not dashes are word characters . I just noticed more differences in the Cntl or Cntl-Shft
    Message 1 of 3 , May 12, 2012
      NT Pro is a bit schizophrenic. It can't make up its mind whether or not
      dashes are word characters .

      I just noticed more differences in the Cntl or Cntl-Shft Left/Right Arrow
      behavior between NT Std and Pro. I also found another non-symmetric
      behavior of NT Std.

      Take these lines:

      xx xx xx xx xx

      xx xx xx xx xx
      -- -- -- -- --
      -- -- xx -- -- xy -- --

      Starting from an end point of line 1 or 3, each Cntl (Cntl-Shft) left/right
      arrow jumps (selects) to the beginning of the next word, "xx". However, for
      line 4, NT Pro jumps (selects) the entire line.
      NT Std consistently treats the dashes as word characters whereas NT Pro
      seems to treat them as spaces (but as word characters under other conditions).

      In line 5, from the BOL, the first Cntl-Right Arrow jumps to the beginning
      of the first word, "xx", consistent with treating the dashes as spaces.
      However, the next Cntl-RA jumps to the following dashes, treating them as a
      word. Upon pressing Cntl-RA again, NT Pro reverts back to treating the
      dashes as spaces.

      In line 5, from the EOL, the first Cntl-Left Arrow jumps to the END of the
      first word it finds, "xy", not the beginning! Either that or it is treating
      the spaces following the "xy" as word characters. The next Cntl-LA jumps
      to the BEGINNING of that word. Subsequent Cntl-LAs repeat the previous
      behavior.

      Similar selection behavior for Cntl-Shft Left/Right Arrow.

      Double clicking on the dashes selects the dashes and the following spaces,
      consistent with treating the dashes as word characters (double click
      behavior per the help file). There may be a precise definition of word
      characters in the NT help file but I couldn't find one.

      Starting from the beginning of the last word in line 1, it takes four
      Cntl-RAs to get to the beginning of the first word of line 3 for both NT
      Std and NT Pro. NT Pro is symmetric in that it takes four Cntl-LAs to
      return to the starting position. However, NT Std jumps back to the start in
      only two clicks, treating any intervening CRLFs as spaces. This is probably
      another Windows anomaly. Other editors are inconsistent as well.

      Although other editors are all over the map regarding treatment across
      CRLFs, they all consistently treat dashes as word characters. While this NT
      Pro behavior has existed since at least v4.95, it should be corrected.

      Namaste', Art
    • John Shotsky
      I think this behavior may be restricted to the keyboard operations, but not true in regex. Performing multiple Finds with w+ finds only the letters. My whole
      Message 2 of 3 , May 13, 2012
        I think this behavior may be restricted to the keyboard operations, but not true in regex. Performing multiple Finds
        with \w+ finds only the letters. My whole library depends on this functionality. Although I don't use the keyboard that
        way, it is clearly erroneous if it is not consistent.

        Regards,
        John
        RecipeTools Web Site: <http://recipetools.gotdns.com/> http://recipetools.gotdns.com/

        From: notetab@yahoogroups.com [mailto:notetab@yahoogroups.com] On Behalf Of Art Kocsis
        Sent: Saturday, May 12, 2012 23:45
        To: NoteTab-Basic
        Subject: [NTB] More Std vs Pro Behavior Differences


        NT Pro is a bit schizophrenic. It can't make up its mind whether or not
        dashes are word characters .

        I just noticed more differences in the Cntl or Cntl-Shft Left/Right Arrow
        behavior between NT Std and Pro. I also found another non-symmetric
        behavior of NT Std.

        Take these lines:

        xx xx xx xx xx

        xx xx xx xx xx
        -- -- -- -- --
        -- -- xx -- -- xy -- --

        Starting from an end point of line 1 or 3, each Cntl (Cntl-Shft) left/right
        arrow jumps (selects) to the beginning of the next word, "xx". However, for
        line 4, NT Pro jumps (selects) the entire line.
        NT Std consistently treats the dashes as word characters whereas NT Pro
        seems to treat them as spaces (but as word characters under other conditions).

        In line 5, from the BOL, the first Cntl-Right Arrow jumps to the beginning
        of the first word, "xx", consistent with treating the dashes as spaces.
        However, the next Cntl-RA jumps to the following dashes, treating them as a
        word. Upon pressing Cntl-RA again, NT Pro reverts back to treating the
        dashes as spaces.

        In line 5, from the EOL, the first Cntl-Left Arrow jumps to the END of the
        first word it finds, "xy", not the beginning! Either that or it is treating
        the spaces following the "xy" as word characters. The next Cntl-LA jumps
        to the BEGINNING of that word. Subsequent Cntl-LAs repeat the previous
        behavior.

        Similar selection behavior for Cntl-Shft Left/Right Arrow.

        Double clicking on the dashes selects the dashes and the following spaces,
        consistent with treating the dashes as word characters (double click
        behavior per the help file). There may be a precise definition of word
        characters in the NT help file but I couldn't find one.

        Starting from the beginning of the last word in line 1, it takes four
        Cntl-RAs to get to the beginning of the first word of line 3 for both NT
        Std and NT Pro. NT Pro is symmetric in that it takes four Cntl-LAs to
        return to the starting position. However, NT Std jumps back to the start in
        only two clicks, treating any intervening CRLFs as spaces. This is probably
        another Windows anomaly. Other editors are inconsistent as well.

        Although other editors are all over the map regarding treatment across
        CRLFs, they all consistently treat dashes as word characters. While this NT
        Pro behavior has existed since at least v4.95, it should be corrected.

        Namaste', Art



        [Non-text portions of this message have been removed]
      • Art Kocsis
        ... In general, the anomalies seem to be worse in the keyboard behavior than in the clips or RegEx. However, we (or at least I), spend a lot of time on the
        Message 3 of 3 , May 13, 2012
          At 5/13/2012 03:42 AM, John wrote:
          >I think this behavior may be restricted to the keyboard operations, but
          >not true in regex.
          >Performing multiple Finds with \w+ finds only the letters. My whole
          >library depends on
          >this functionality. Although I don't use the keyboard that way, it is
          >clearly erroneous if
          >it is not consistent.

          In general, the anomalies seem to be worse in the keyboard behavior than in
          the clips or RegEx. However, we (or at least I), spend a lot of time on the
          keyboard and getting frustrated over strange behavior does not help for a
          pleasant user experience.

          Testing stuff like this takes an enormous amount of time. It sometimes
          doesn't look like it after the critical variables are identified but
          getting there is tedious and slow. I had to cut off testing with the
          keyboard but I did check ^!Select Word(s) and that seemed to work
          consistently.

          I hope Eric appreciates the work we are putting in testing his program.

          art
        Your message has been successfully submitted and would be delivered to recipients shortly.