search

isamert / scli

a simple terminal user interface for signal messenger (using signal-cli)
GNU General Public License v3.0
444 stars 40 forks source link

Customizable key bindings #111

Closed exquo closed 3 months ago

exquo commented 3 years ago

Implements #107. This PR is intended as an "evolving prototype" rather than a complete implementation.

Use it like this:

scli --bind copy_message:y --bind=delete_message:d/p

Or, in config file

sclirc
------
bind=copy_message:y
bind=delete_message:d/p
exquo commented 3 months ago

Implemented in 16778d61588c82cb22fbd82e11d96d9bdbb9dc02.

Unlike the 2d7fd74d08b73d8c9765d962308af3a595233cc1 above, it does not use contexts / scopes. They were used in checking for key collisions, i.e. mapping of a single key to multiple actions (that would be a problem). However, there is no ambiguity if those actions can only occur in different situations. For instance, when the focus is on the contacts list, the → key opens the conversation with the highlighted contact; whereas if the focus is on one of the messages in the chat, the → key opens the message's attached files - therefore there is no collision, as the spheres of keys' actions are separate. The idea with having contexts was to divide all actions into such spheres (e.g. contacts, chat, input, etc), so that only the key bindings within each context / scope should be unique.

However, the logic in keypress() functions that process key presses can be arbitrary complex, and the context-based division as described above might not be sufficient. For example, key r could be used in a chat to reply to a message; that key is also used to re-send the failed-to-send messages. Despite these two actions being mapped to the same key in the same scope (chat / messages list) there would be no collision because re-sending would only be applicable to messages for which sending has failed, whereas replying acts on the received (and the successfully sent) messages. So there is no "overlap" or uncertainty about which of the actions should be used. In general, any such division of actions into applicable scopes can not foresee all such possibilities.

Therefore, the scopes are not used at all, and there is no collision checking. It is assumed that a user will notice an unexpected program response after making a problematic remapping; of course there should be no collisions in the default key map.