search

gmoranfdez / lanterna

Automatically exported from code.google.com/p/lanterna
GNU Lesser General Public License v3.0
0 stars 0 forks source link

AltAndCharacterPattern conflicts with escaped key basic patterns #100

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
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 commented 9 years ago 
100th issue! Congratulations!

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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
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 commented 9 years ago 
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 commented 9 years ago 
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