Empyreus / lanterna

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

CtrlAndCharacterPattern should exclude \r #64

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
I'm serving Lanterna over telnetd as a text terminal.

OS X terminals, such as Terminal.app or iTerm2, send Enter as \r\u0000 
(carriage return followed by null), which was not recognized by the provided 
key mapping profiles. 

I added my own profile containing this pattern. This correctly recognized it as 
Enter, but it was also being wrongly intercepted by the 
CtrlAndCharacterPattern, because \r is int 13 and appears to be a control 
character. The pattern excludes \n and \t, but not \r. I think it should.

Once I've modified CtrlAndCharacterPattern#match method to also test for \r, 
everything worked correctly.

I haven't seen a way to do this other than modifying the source. There is no 
access to the collection of key mapping profiles provided in a text terminal, 
other than adding to it.

Original issue reported on code.google.com by sivan.mo...@gmail.com on 25 Jan 2013 at 1:04

Attachments:

GoogleCodeExporter commented 9 years ago
Patch is applied, please give it a try if you have a chance to.

Original comment by mab...@gmail.com on 27 Jan 2013 at 3:52

GoogleCodeExporter commented 9 years ago
This works.

However, I found a similar problem when using DOS or PuTTy clients on Windows. 
The Enter key sends the pattern \r\n. When added to the PuttyProfiles, Enter is 
recognized correctly. Attached patch.

Original comment by sivan.mo...@gmail.com on 30 Jan 2013 at 12:18

Attachments:

GoogleCodeExporter commented 9 years ago
That's odd, I haven't seen this behaviour with Putty before. Are you running it 
with the default settings?

Original comment by mab...@gmail.com on 30 Jan 2013 at 12:51

GoogleCodeExporter commented 9 years ago
Just plain Putty and DOS telnet connections.

I am serving lanterna as the shell for the telnetd library, sharing the input 
stream. To my knowledge, the input stream is not modified in any way. I can 
look further if you have other ideas.

Original comment by sivan.mo...@gmail.com on 30 Jan 2013 at 1:26