AltAndCharacterPattern conflicts with escaped key basic patterns

[GoogleCodeExporter]

When a terminal sends F1 as "\u001BOP", it should get matched by:

                    new BasicCharacterPattern(new Key(Key.Kind.F1), ESC_CODE, 'O', 'P'),    //Cygwin

Instead, it's matched prematurely by AltAndCharacterPattern, because its 
isCompleteMatch method returns true as soon as two characters are tested (with 
the first being an escape, and the second a letter or digit):

    @Override
    public boolean isCompleteMatch(List<Character> currentMatching) {
        if(currentMatching.size() != 2)
            return false;
        if(currentMatching.get(0) != KeyMappingProfile.ESC_CODE)
            return false;
        if(!Character.isLetterOrDigit(currentMatching.get(1)))
            return false;
        return true;
    }

Because of this, The F1 key will never be recognized.

Other issues that compound the problem:

1. InputDecoder uses a HashSet to store all character patterns. This makes the 
order of pattern tests unpredictable. 
2. Even if it was an ordered collection, there would be no way to retrieve and 
reorder it. 
3. InputDecoder itself is instantiated in the StreamBasedTerminal constructor, 
precluding a user provided one.

Original issue reported on code.google.com by sivan.mo...@gmail.com on 14 Feb 2014 at 12:40

[GoogleCodeExporter]

100th issue! Congratulations!

Original comment by mab...@gmail.com on 16 Feb 2014 at 7:31

[GoogleCodeExporter]

So, basically, this problem should be solved by the new input decoder I wrote a 
while back but never switched on. Can you try re-running with 
"-Dcom.googlecode.lanterna.input.enable-new-decoder=true"? I know this new 
input decoder has some issues too, but it should catch this problem where a 
substring of a sequence matches.

Original comment by mab...@gmail.com on 16 Feb 2014 at 7:34

• Changed state: Accepted

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hi Martin. Unfortunately, the new version with the optional decoder had a new 
problem with getting stuck on attempting to read the terminal size. We've 
worked around the original input decoder issues with reflection.

I'll try to write a unit test that demonstrates the problem.

Original comment by sivan.mo...@gmail.com on 20 Feb 2014 at 12:00

[GoogleCodeExporter]

Yep, I've noticed that too. The version in 3.0 (snapshot build, master branch) 
seems to have fixed this problem. I'll see if I can backport it to 2.1.x

Original comment by mab...@gmail.com on 30 Mar 2014 at 12:50

[GoogleCodeExporter]

I've backported some of the new input decoder logic to release/2.1.x branch and 
deployed a new 2.1.8-SNAPSHOT build. Please try it out (you'll still need the 
same system property set to bypass the old decoder) if you have a chance.

Original comment by mab...@gmail.com on 30 Mar 2014 at 1:05