Add support for rebinding/remapping keys

[alfonsrv]

In Terminal on macOS Ctrl + d closes processes, while everything including the Meta key (aka Alt) is translated to a special character instead – making Alt + Enter not possible to use, hence making the zulip-terminal client a read-only client on macOS if the native Terminal configuration is not altered.

This could also help prevent tmux collisions by giving users the freedom to choose their key-bindings freely.

[neiljp]

This is actually possible by editing the keys.py file in the source distribution, though granted this is not straightforward or sustainable with upgrades. We have discussed the issue in the context of an appropriate key for sending messages previously, including in #294 . Do you have any thoughts given that discussion?

[alfonsrv]

Editing the keys.py file indeed does not seem sustainable over the long run. If you ask for my opinion, I think a seperate [keybindings] section within the config would be desirable.

We could either work with a prefix – such as tmux, e.g. C-z (^Z) (is not used by default for any application I know of) – and then s for send. I think that behavior while indeed having a steeper learning curve would be desirable as it would give way more flexibility instead of having to battle with previously existing shortcuts. Or we just work with static keyboard bindings, however I think the collisions are too likely given what terminal power users such as the one using zulip-terminal use on a regular basis.

As for a default shortcut for sending messages, I think C-Space (^@) could work?

[neiljp]

I agree that making keybindings configurable outside of the source is the long term solution, and we could reserve this issue for that.

Given the ongoing debate over #294, setting sending keys in particular seems like the priority for now, whether as a configuration option or resolving the problem in another way. I recommend we discuss this aspect in that issue, and also in #zulip-terminal. There are past topics in that stream on chat.zulip.org such as "Key for sending msg" and "Contributing & Send Message shortcut". Looking back in the history I'm wondering if we want to re-try using a modifier with enter.

Re MacOS I believe other known ZT users use alternative emulators due to issues with eg. color support, as per #662, which could be a workaround to the keyboard issue for you.

[sumanthvrao]

@alfonsrv A hack which makes Alt + Enter work for me with Mac OS was to toggle this setting under Terminal > preferences > Profiles > Keys from Meta to ESC+

Note: I use iTerm2 terminal emulator and not the default one.

[alfonsrv]

@sumanthvrao as mentioned initially, I do not want to adapt my native Terminal to a product; it should be the other way around. Thanks for the suggestion tho!

@neiljp well as mentioned regarding #294, ^z or ^l could be a god global alternative. regarding #662; colors work fine in native Terminal under tmux – automatically choosing dark theme even.

[neiljp]

@alfonsrv ctrl + L is a readline key (clear text) and also is known as a screen-redraw key in terminals. ctrl + Z is the suspend key which we don't support right now but could support in future, so I'm wary of using it for such a significant key as sending messages. Selecting a good 'standard' is not as easy as it appears!

[neiljp]

@alfonsrv We're currently discussing the keys on chat.zulip.org, but it does seem like the use of mac Terminal is currently limited by the keybindings it has chosen compared to other systems. ctrl <space> seemed reasonable but itself fails under iterm2 based on reports so far (closing the terminal!), and presumably platform-specific combinations with cmd on mac are unwise much like use of the windows keys on windows/linux systems (and cmd <space> reportedly is taken).

This is continuing off-topic, but do the colors look like the screenshot at https://github.com/zulip/zulip-terminal for you in Terminal/tmux? That's great if they do, but we had reports they didn't work in mac Terminal before I think (as per #662)

[alfonsrv]

I see. Well as previously suggested I think life would be much easier if shortcuts were prefixed or if keys were more accessibly rebindable using the .zuliprc config.

As for the theme – whenever I am in tmux it seems to default to the zt_dark theme, even though it is not specified in the configuration file. Sorry I had to blur most of it out, but I'm sure you get the idea https://imgur.com/ox6iRUU

alfons@NullX ~ % zulip-term
Loading with:
   theme 'zt_dark' specified with no config.
   autohide setting 'no_autohide' specified with no config.
Welcome to Zulip.
Loading -

[neiljp]

For the record, with #662 merged we've recorded the state of various emulators that we know so far.

[zulipbot]

Hello @zulip/server-hotkeys members, this issue was labeled with the "area: hotkeys" label, so you may want to check it out!

[neiljp]

Supporting even a simple version of this would enable us to unblock use by more users and give details of how to work around this between releases.

We likely want to work on #678 first to enable separation of config for profiles and options, though we could always migrate to that later? We likely want a centralized config for this since generally this is unlikely to be specific to a profile, though we could support a --keymap mapname much like we propose having zulip-term profilename for #678.

[neiljp]

Just thinking of this issue again after further discussion on chat.zulip.org regarding use of non-latin keyboard inputs, which is related to an older server repo issue zulip/zulip#7517. That is in the direction of internationalization which is not a high priority right now. However, this is very similar to the intent of this issue, namely to allow for additional/custom keys - if I switch into a different keyboard layout, perhaps I want certain keys to still perform the same actions. See the linked server issue for more discussion.

[supermarin]

Resurrecting this thread after trying to figure out how to map Send to just Enter. Is there any plans to support configurable keys in zuliprc?

[neiljp]

@supermarin Thanks for showing an interest in the feature!

I had hoped that we might migrate the configuration file sooner since that could make things simpler (as above), but contributors have been involved with other areas. That does not mean that a configuration option for this could not be developed outside of that migration, and some recent changes could make integrating this a little easier too.

Any contributions toward this would be welcome, whether as a PR, discussion of minimal features, or in terms of what you would wish to change, or the configuration format. As per the start of my comment here #680 (comment), all that is necessary is an adjustment of the dict in keys.py; there I suggested it could be manually changed (and still can be), whereas this feature would involve at minimum a patching of that dict at runtime based upon string-pairs in a configuration file (command -> key).

A fuller implementation would likely require validating those keys (at least for a subset of commands), and supporting migration of command strings from one version of ZT to another, which was historically a reason why we did not prioritize this issue. Documentation would also be useful, of the updated configuration options, as well as what keys/values are possible (pointing to source files and urwid documentation, in the first instance).

[supermarin]

As per the start of my comment here #680 (comment), all that is necessary is an adjustment of the dict in keys.py

Yep seen that one, but unless you're running the project from source, this isn't a feasible option for majority of users IMO.

A fuller implementation would likely require validating those keys (at least for a subset of commands), and supporting migration of command strings from one version of ZT to another, which was historically a reason why we did not prioritize this issue.

If you keep the same key code names as the dict keys in KEY_BINDINGS, i.e. SEND_MESSAGE in this case, then an assertion somewhere on config load that the mapped key code is in KEY_BINDINGS would verify the mapped key code is indeed an existing one, and it should fail in the future if the key codes change. If I'm missing something obvious let me know, but IMO it's better to roll out something simple and improve over it later, vs the current status :)

[neiljp]

Re editing keys.py manually, yes, that is likely not feasible for those users who are not familiar with how python applications are installed. However, manual configuration files are not always easy for users - it depends on the audience. At one point we had a draft where settings could be toggled in the application, which would be the ideal final result :)

Regarding implementation, we can certainly simply error-out before loading, if a key code name from the configuration file is not in KEY_BINDINGS - and that would not be much more complex than an assert.

(note that the part you linked to for config load concerns the validity/consistency of default configuration settings)

[WuMingIT]

Adding my experience here: on Terminal app v 2.8.3, bash v 3.2.57(1), Python v 3.8.12, Zulip Terminal v 0.7.0 CTRL+d does submit a new message. But UI sometimes isn't updated so user won't notice. I did notice only because one of my team asked why I submitted the same message three times.

[neiljp]

@WuMingIT If it does submit a new message, this doesn't sound quite like the same issue?

Which Terminal app is this? for Mac?

[WuMingIT]

From OP’s first line “In Terminal on macOS Ctrl + d” and from my own “on Terminal app v 2.8.3”. Yes, subject is macOS here.

As for the same issue, perhaps OP did not realize a new message was, in fact, submitted. With CTRL+d at least.

[neiljp]

@WuMingIT I appreciate your feedback here 👍 I've tried to explain my earlier response in more detail below.

The reason I wanted to clarify your platform, is that "Terminal app" doesn't narrow down the application name, unless perhaps it's the default one on Mac - and even then, it's not necessarily guaranteed.

From the beginning this specific issue focused on the idea of a general solution to the specific problem of ctrl d/alt enter in the default terminal emulator on MacOS, via being able to remap/rebind keys, which could benefit users in general. I'd like to retain that as the focus of this issue for now.

Regarding the known challenge with using the MacOS default Terminal app with zulip-terminal, we previously added a note to the supported terminal emulator section in the FAQ. That points to this issue, and we could certainly summarize alternatives based on some of the comments above - eg. if people are willing to adjust their terminal emulator settings, or use a different emulator. Even once the remapping of keys is added (this issue), this would be useful, since some may find it simpler to do so instead of adjusting zulip-terminal settings. I've just opened #1443 to track this.

What I meant by how it sounds like you are describing different (though related) issue(s), is that

1. for some reason ctrl d is working for you, under the emulator which previously had problems, ie. it sends messages (so related to the original problem, not the original suggested general solution)
2. it seems the UI doesn't always update for you, to show that a message has been sent

For point (1), I'd welcome any details from you which could help everyone understand the situation better, ie. why this is working for you, but didn't for others previously. This comes under the remit of #1443, so I'd suggest following up there, though it may be easier to discuss in the #zulip-terminal stream on chat.zulip.org in a new topic.

For point (2), this sounds like it could be an independent bug, so if you're able, please do file a bug report with as much detail as you can!

[WuMingIT]

I need to rectify: Python version used by my zulip term installation is 3.12. Have two versions of Python installed. OP submitted in early 2020. I don’t see a macOS version mentioned but purely from the date of submission I can infer he was using 10.13 or earlier. I am on macOS 10.13 High Sierra. OP was also likely using zulip term v 0.4 or 0.5 vs 0.7 of mine. More than a year old by itself. Finally OP did not share a Python version but was most likely earlier than mine. I did search .zt_venv directory for a log file. Found none. I know nothing about Python: please advise.

For point (1), I'd welcome any details from you which could help everyone understand the situation better, ie. why this is working for you, but didn't for others previously. This comes under the remit of #1443 <#1443>, so I'd suggest following up there, though it may be easier to discuss in the #zulip-terminal stream on chat.zulip.org in a new topic.

You may excuse me for updating this bug since it is strictly a macOS related issue. Toolset used between then and now did change quite a bit. Perhaps log file when found will help to clarify what blocked, and then un-blocked, ui updating itself. On attempts after multiple re-launches there was no updating at all. Not by sending a message. Not by receiving a message. Not by forcing refresh. It does update now during my couple of other attempts at using it. I would prefer to use term over the electron based UI.

For point (2), this sounds like it could be an independent bug, so if you're able, please do file a bug report with as much detail as you can!

It may not be a new bug. As mentioned before, OP may not have been aware messages were in fact being sent. Without him noticing. As it happened to me. Thanks.

…

On 28 Nov 2023, at 16:32, Neil Pilgrim ***@***.***> wrote: — Reply to this email directly, view it on GitHub <#680 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALHEXDBMR7MLY2QKHLQMCUTYGWOTPAVCNFSM4NYI6YYKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBSHEZTGMZRGMYA>. You are receiving this because you were mentioned.

[WuMingIT]

I have been using -term yesterday and today and it seems to work as expected now. Message send, edit, delete, quote. After adding the proper configuration notifications work as well.

[Niloth-p]

@zulipbot claim

[zulipbot]

Hello @Niloth-p!

Thanks for your interest in Zulip! You have attempted to claim an issue without the label "help wanted". You can only claim and submit pull requests for issues with the help wanted label.

If this is your first time here, we recommend reading our guide for new contributors before getting started.