Two related issues in KeyMagic input.

[GoogleCodeExporter]

#WZ 1.8 nightlies

---output from log:
User typed:  (1000)(103a)(200b)(1000)f
   $row3K[*] => $row3U[$1]
      ==>(1000)(103a)(200b)(1000)(103a)
   $ZWS + $consU[*] + $killer => $2 + $3
      ==>(1000)(103a)(200b)(1000)(103a)(103a)
....etc.

Two issues:
  1) First, we currently match like this:
       (1000)(103a)(200b)(1000)f <VK_KEY_F>
     ...when we should actually be doing:
         (1000)(103a)(200b)(1000)f 
      || (1000)(103a)(200b)(1000)<VK_KEY_F>
     This can be fixed by checking indexes now, but I think it's better to
flag entries that "have a VK" item, and then just skip them once we've
matched a single VKEY. 

  2) (1000)(103a)(200b)(1000)(103a) should become:
     (1000)(103a)(1000)(103a), not:
     (1000)(103a)(200b)(1000)(103a)(103a)
    This appears to be some issue with either groups or substr(). This
causes an infinite loop, of course.

Also, we might consider a bonus issue:
  1) We should avoid adding rules to the "considerations" list if they fail
to match on the first letter. This will require some restructuring, but it
makes sense logistically.

Original issue reported on code.google.com by seth.h...@gmail.com on 5 Apr 2010 at 5:59

[GoogleCodeExporter]

2. is partly done; matches are skipped if they contain a VK_*, but they still 
aren't
handled properly yet.

Original comment by seth.h...@gmail.com on 5 Apr 2010 at 8:25

[GoogleCodeExporter]

Part 2 done.
Bonus part will have to wait until 1.9

Original comment by seth.h...@gmail.com on 5 Apr 2010 at 8:31

[GoogleCodeExporter]

(Note: I meant "part one" when I said "part two" above). NOW working on Part 2.

Original comment by seth.h...@gmail.com on 5 Apr 2010 at 8:32

[GoogleCodeExporter]

Fixed. Still looping forever, but for a different reason.

Original comment by seth.h...@gmail.com on 5 Apr 2010 at 9:01

• Changed state: Fixed