Ticket #3 (closed defect: fixed)

Opened 7 years ago

Last modified 6 years ago

The tab key produces the event EvKey (KASCII 'i') [MCtrl] instead of the expected EvKey (KASCII '\t') []

Reported by: coconnor Owned by: coconnor
Priority: major Milestone:
Component: component1 Version:
Keywords: Cc:

Description

  1. cd vty/test
  2. runghc Test.hs
  3. Press tab

the event printed is EvKey? (KASCII 'i') [MCtrl]

Change History

Changed 7 years ago by coconnor

  • owner changed from somebody to coconnor
  • status changed from new to assigned

The raw bytes read from STDIN for 4 tabs followed by ESC are:

'\t'
'\t'
'\t'
'\t'
'\ESC'

Which is what is expected. Looks like it's post STDIN read where the error occurs.

Changed 7 years ago by coconnor

Using a MacBook? Pro, Terminal, Mac OS X 10.5.3 the control-i sequence produces a sequence identical to the tab key. In the classify table here is a mapping from the tab key to KASCII tab:

("\t",(KASCII '\t',[]))

but there is also a mapping from the tab key to control-i:

("\t",(KASCII 'i',[MCtrl]))

Changed 6 years ago by coconnor

They are equivalent input for many terminals. I'm not sure why the control-I event is now selected over the tab event. In this case "\t" should trigger only a KASCII '\t' event. Never a CONTROL-I event. However, I could see the desire for:

  1. Supporting CONTROL-I events for those terminals that do differentiate between the two.
  2. Optionally remapping CONTROL-I to TAB implicitly.

Changed 6 years ago by anonymous

Reproduced in VTY 3.0.1. So not a regression caused by new input thread handling. Also does not explain exactly *why* there was a regression in yi!

Changed 6 years ago by coconnor

  • status changed from assigned to closed
  • resolution set to fixed
Note: See TracTickets for help on using tickets.