Ticket #6 (assigned defect)

Opened 6 years ago

Last modified 6 years ago

The same input can produce a different event sequence depending on rate getEvent is called.

Reported by: coconnor Owned by: coconnor
Priority: major Milestone:
Component: Uncategorized Version:
Keywords: Cc: jeanphilippe.bernardy@…

Description

  1. Run test/Test.hs
  2. Escape key down ; Escape key up ; Key ':' down ; Key ':' up
  3. Apply the attached patch to Test.hs. This patch adds a delay between getEvent calls.
  4. Run test/Test.hs
  5. Escape key down ; Escape key up ; Key ':' down ; Key ':' up

The expectation is that the same input sequence from the terminal will produce the same event sequence from getEvent regardless of the delay between times getEvent is called.

In the first run the test program will exit before reading in the ":" character. In the second run the test program will likely recognize the input as the event "EvKey? (KASCII ':') [MMeta]" Which is different than the sequence of events "EvKey? KEsc []" ; "EvKey? (KASCII ':') []" that was produced without the added delay.

Attachments

add_delay.dpatch (5.9 kB) - added by coconnor 6 years ago.

Change History

Changed 6 years ago by coconnor

Changed 6 years ago by coconnor

  • status changed from new to assigned

Changed 6 years ago by coconnor

I'm not even sure it's possible to differentiate key up from key down in the input stream. However it should be possible to provide more predictable behavior.

Perhaps by always sampling STDIN at a regular rate regardless of timing of getEvent calls. Then apply internal rules for when key sequences involving meta should be considered individual or merged.

Seems like a problem other systems have run into. How were they resolved?

Changed 6 years ago by coconnor

Pushed patch that shoudl improve this situation.

Input now works something like:

  1. Block until some input is available
  2. Read all available input
  3. Translate all new input into events
  4. Repeat

This is all done in an IO thread and seems to result in a more consistent event stream for the same input.

Changed 6 years ago by coconnor

The issue can still be hit, but the situation has improved.

Changed 6 years ago by jeanphilippe.bernardy@…

  • cc Possibly, this, could, be, a, parameter, so, that added

Now I get the converse behaviour: Meta-x is sometimes interpreted as Esc x. This appeared when I installed ubuntu 8.10, so it's hard to track down exactly.

Arguably it's possible that M-x ends up as two separate reads.

I have a patch that fixes this by interpreting Esc x as Meta-x if the delay between the keypresses is less than 1 ms. Of course it's still possible to type as fast as that, so it's not ideal.

The best would be to configure the terminal to send meta codes with the high bit set instead of a separate esc. I'm not sure if this will mess with utf-8 though.

Changed 6 years ago by anonymous

  • cc jeanphilippe.bernardy@… added; Possibly, this, could, be, a, parameter, so, that removed

Changed 6 years ago by jeanphilippe.bernardy@…

http://invisible-island.net/xterm/ctlseqs/ctlseqs.html#Alt%20and%20Meta%20Keys

Apparently having (setting the bit vs. ESC) is possible only for xterm, by setting resources.

I don't see a good solution for this. At the moment I have to use my customized version of vty :(

Note: See TracTickets for help on using tickets.