Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support comparators for matching keyboard input to meta and ctrl keys #58

Open
jquast opened this issue Oct 9, 2015 · 5 comments
Open

Comments

@jquast
Copy link
Owner

jquast commented Oct 9, 2015

Problem

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') ?

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) 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().

@jquast
Copy link
Owner Author

jquast commented Oct 20, 2015

Second proposal suggested in issue description

@thomasballinger
Copy link

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?

@jquast
Copy link
Owner Author

jquast commented Feb 1, 2016

next action: write brief design document for first proposal

@jquast
Copy link
Owner Author

jquast commented Feb 2, 2020

see also #144

@jquast
Copy link
Owner Author

jquast commented Oct 17, 2022

Related, #222

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants