Keymap configuration (or at least extraction)

[neiljp]

It would be really useful to be able to know which keys are used by the library, to avoid conflict with other keys, or to show a list of shortcut keys. Currently the keymap is in the keypress command; does it seem reasonable to extract this, and potentially include metadata regarding each one, if there is not already?

I could investigate another PR, if this would be a reasonable idea.

[rr-]

You mean being able to know in the programmatical sense?

Do you want to go a step further and be able to manipulate this keymap?

[neiljp]

In increasing degrees of convenience, it would be useful to:
a) know which keys are handled by this library (to sense key conflicts)
b) know what each key "does" (symbolic strings, actual text, ...) (eg. to show 'help')
c) potentially (?) remove keys from the map (to manually resolve conflicts if desired)
d) in some future version, hypothetically have a map which translates keys to 'commands'? (full customization)

(a) or (b) are the short-term options I was considering for this issue.

(c) or (d) could allow much more customization and eg. sets of keymaps, extending beyond just readline, perhaps.

[rr-]

Sorry for the late reply. Pushed 8f13b26 which moves the keymap to the constructor. That way, you should be able to subclass ReadlineEdit and manipulate its keymap however you need. Let me know if this change is sufficient for your needs, and if it is, I'll publish a new version on PyPI. Thanks :)

[neiljp]

@rr- No problem - this is great as a first iteration for (a), and it would be useful to have the other commit from #7 in a release too.

I am investigating another issue with zulip-terminal that may or may not be a urwid_readline bug, for multiline boxes with previous_line/next_line - I was checking the tests and didn't see any for the multiline case? If this is an urwid_readline bug, it might be good to get this in & fixed too, if it's not too difficult.

[rr-]

c) and d) should be completely doable, though (that's what I meant by subclassing ReadlineEdit):

class MyReadlineEdit(ReadlineEdit):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        del self.keymap['ctrl a']
        self.keymap['ctrl a'] = …

As for b), all you have to do is to compare the keymap values with the member functions. They're public for a reason.

As for the bug, it should go into a separate ticket.

[neiljp]

Oh, yes, sorry, I meant to agree on the subclassing point, and was thinking about (b) to myself, still.

I referenced the other issue since I had only just remembered it and thought it pertinent in the context of releasing now or later.

[neiljp]

@rr- To be clear, if you're fine with making a new release, that would be fine with me :)

[rr-]

Release 0.9 available on PyPI.