You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ctrl keys, such as ^C are not considered sequences and must be matched by their raw escape codes. We propose a change:
- if term.inkey() == '\x03':
+ if term.inkey() == term.KEY_control('c')
Furthermore, the legacy (and not recommended for modern applications, IMO) to support alt or meta by escape,
# TODO(jquast): "meta sends escape", where alt+1 would send '\x1b1',
# what do we do with that? Surely, something useful.
# comparator to term.KEY_meta('x') ?
# TODO(jquast): Ctrl characters, KEY_CTRL_[A-Z], and the rest;
# KEY_CTRL_\, KEY_CTRL_{, etc. are not legitimate
# attributes. comparator to term.KEY_ctrl('z') ?
How would we support the advanced ctrl, shift, and alt combinators of #73 ?
First Proposal
New methods KEY_control(ucs) and KEY_meta(ucs), returning a Sequence instance(?), \x03 for Ctrl-C and \x1b[c for Alt-C, that can be compared for equality for a given sequence (by their equivalent raw string value). As Unicode-derived class Sequence, this should work without supporting stub code for both left and right-hand side operations. The code value should remain its numeric ascii value for control. For meta characters, code should be value None.
Second Proposal
Further decorate the Keystroke class to provide new methods:
control (or ctrl or both) alt (or meta or both) shift (may not support... difficult)
Which accepts an optional 1-unicode-character input in range of ascii (a-zA-Z, punctuations, etc.).
So that, with ctrl-c, the unicode string is u'\x03' and its method .ctrl() returns True, .ctrl('c') returns True, and .ctrl('z') returns False.
Similarly, with alt+x, the unicode string is u'\x1bx' and its method .alt() returns True, .alt('x') returns True, and .alt('p') returns False.
Third Proposal
Support .is_compound_format_testing() tester, somewhat like blessings project, example:
if term.inkey().is_alt_shift('z'):
# fancy way of saying alt+Z was pressed.
if term.inkey().is_ctrl_shift('c'):
# may never test true, dragons be here
inp = term.inkey()
This would for example support testing key combinations such as
#define SHIFT_ALT_CTRL_PF7_KEY "\033[18;8~"
shift is difficult. In '\x03' (^C), we would test that shift is not pressed. But it could just as easily be pressed, and we wouldn't know. We would chose false unless it tested against upper().
The text was updated successfully, but these errors were encountered:
I most like the first proposal because it seems most straightforward.
I could imagine pining for things like SHIFT_ALT_CTRL_PF7_KEY in the future, but have no interest in them now. It seems like these could be added to term as well in the future?
Problem
Ctrl keys, such as ^C are not considered sequences and must be matched by their raw escape codes. We propose a change:
Furthermore, the legacy (and not recommended for modern applications, IMO) to support alt or meta by escape,
as well as erikrose#27 (comment)
and erikrose#44
Note: this backported from upstream erikrose#98
How would we support the advanced ctrl, shift, and alt combinators of #73 ?
First Proposal
New methods
KEY_control(ucs)
andKEY_meta(ucs)
, returning a Sequence instance(?),\x03
for Ctrl-C and\x1b[c
for Alt-C, that can be compared for equality for a given sequence (by their equivalent raw string value). As Unicode-derived class Sequence, this should work without supporting stub code for both left and right-hand side operations. The code value should remain its numeric ascii value for control. For meta characters, code should be value None.Second Proposal
Further decorate the Keystroke class to provide new methods:
control
(orctrl
or both)alt
(ormeta
or both)shift
(may not support... difficult)Which accepts an optional 1-unicode-character input in range of ascii (a-zA-Z, punctuations, etc.).
So that, with ctrl-c, the unicode string is
u'\x03'
and its method.ctrl()
returns True,.ctrl('c')
returns True, and .ctrl('z') returns False.Similarly, with alt+x, the unicode string is
u'\x1bx'
and its method.alt()
returns True,.alt('x')
returns True, and.alt('p')
returns False.Third Proposal
Support .is_compound_format_testing() tester, somewhat like blessings project, example:
This would for example support testing key combinations such as
shift is difficult. In '\x03' (^C), we would test that shift is not pressed. But it could just as easily be pressed, and we wouldn't know. We would chose false unless it tested against upper().
The text was updated successfully, but these errors were encountered: