Improve default keybindings #1399
Comments
imsnif
added
the
ease of use
|
I'm still searching how can use this on my new MacBook 😂 |
|
In macOS with iTerm, I was able to get You can find the setting in iTerm under
But I really need proper |
|
Plus one to this issue. As a mac user myself who was interested in checking out Zellij as an alternative to tmux, I have felt a clear communication that Zellij is not meant for me. If the Zellij community wants this app to be used by mac users, than this problem needs to be addressed. Zellij advertises itself as being out-of-the-box ready, and yet it displays impossible to use short cuts (alt key) to mac users right on the home screen. |
|
Here's a gist of a set of keybinding which I think may solve this issue to a certain extent: https://gist.github.com/samholmes/70bc8b553a2ae888239705904f4fd01c Vim-StyleThe keybindings draw heavy influence from Vim in that Normal mode is actually "Insert" mode and Pane mode is actually "Normal*" mode. This is because Pane is where all the other modes are reachable from with single key motions as well as main navigation actions. In Vim, users always start from Normal mode, not Insert, so this is also reflected in the config. I'll use an asterisk to denote when I mean the renamed Pane more (Normal*). By defaulting to a vim-style normal mode, we have a lot quicker access to movement and other actions (commands) without requiring modifiers. This really makes it easier to choose cross-platform bindings (avoiding Alt on macOS). While in Normal* mode, the user is able to be swift and the tool can enable more complex gestures as the tool evolves. For example, With an Insert mode, the user can pop-in a pane (with either Therefore, in order to unbind the Tab ModeWith a focused Normal* mode, Tab mode is not really needed as it is. All tab actions are bound to commands using the Ctrl modifier. Here are a few (see gist for full list):
I chose this setup mainly because it's not glaringly obvious, visually, whether a user is in Tab mode. Perhaps if the Tabs were highlighted instead of the panes, this would make a Tab mode more useful. Though, I feel like tabs are too important to be at distance from Normal* with another move (though I could be wrong). Solving Escape with an Integration StandardSo far, there is now way to delegate the Escape key to a program while in Insert mode which leaves us with the Locked mode workaround. However, I wonder if it's possible to send the Escape key sequence to the shell program running in the pane and have it return a character sequence back through stderr or some other stream to signal that it is handling it. This would mean that a program could acquire the control over Escape if it has integrated support for this standard. Most programs will not support this standard and so the user will have to fallback to using Locked mode, however programs may adopt this standard over time, especially if it is picked up by other terminal multiplexers. I'm not certain if this will be feasible, but I imagine one could discover if it is possible for programs to consider to signal to the parent program that it is acting on the Escape key. EDIT: I added a Tab mode as an alternative option than tab actions from Normal*. |
Less ModesI've since been playing with a particular configuration which uniquely simplifies the modes and UX for the tool. It doesn't try to emulate Vim as much as my previous post and removes two modes: Lock and Tab. Here is some explanation on how this was acheived. In order to remove Lock mode, we must remove the need for lock mode. The need for lock mode is to turn off keybindings that would interfere with the use of a shell program within the pane. To eliminate this problem, there is only one single binding in Normal mode: Tab mode is removed completely in favor of a single mode to control tabs and panes (Pane mode in the config file). Instead of requiring an extra mode, the user can hold control while in Pane mode for tab navigation using While in any Zellij mode other than Normal, Rename, or SearchInput, the spacebar will change back to normal. This makes it so easy to get back into Normal mode from nearly anywhere to insert commands. The spacebar is a way to clear the Zellij control seamlessly. By having less modes, it is very easy to build that muscle memory and use the tool swiftly. The two things to remember are Here's the config.yaml for a Lock-less and Tab-less configuration. #
# Lock-less and Tab-less:
#
keybinds:
normal:
- unbind: true
# Switch Modes (only one switch)
- action: [TogglePaneFrames, SwitchToMode: Pane]
key: [Char: "\x00"]
locked:
- unbind: true
pane:
# Common:
- unbind: true
- action: [ TogglePaneFrames, SwitchToMode: Normal]
key: [ Char: " ", Char: "\n"]
# Switch Modes
- action: [SwitchToMode: Resize]
key: [ Char: 'r']
- action: [SwitchToMode: Scroll]
key: [ Char: 's']
- action: [SwitchToMode: Move]
key: [ Char: 'm']
- action: [SwitchToMode: Session]
key: [ Char: 'o']
- action: [SwitchToMode: EnterSearch, SearchInput: [0]]
key: [Char: '/']
- action: [Quit]
key: [Ctrl: 'q']
# Nav
- action: [MoveFocus: Left]
key: [Char: 'h', Left]
- action: [MoveFocus: Right]
key: [Char: 'l', Right]
- action: [MoveFocus: Down]
key: [Char: 'j', Down]
- action: [MoveFocus: Up]
key: [Char: 'k', Up]
# Mode Actions
- action: [ NewTab: ,]
key: [Char: 'n']
- action: [NewPane: ]
key: [Char: 'K']
- action: [NewPane: Down]
key: [Char: 'J']
- action: [NewPane: Right]
key: [Char: 'L']
- action: [NewPane: Left]
key: [Char: 'H']
- action: [SwitchToMode: RenamePane, PaneNameInput: [0]]
key: [Char: 'c']
- action: [CloseFocus]
key: [Ctrl: 'd']
- action: [CloseTab]
key: [Ctrl: 'D']
# Tab Actions
- action: [ NewTab: , TogglePaneFrames, SwitchToMode: Normal]
key: [Ctrl: 'n']
- action: [GoToPreviousTab]
key: [Ctrl: 'h']
- action: [GoToNextTab]
key: [Ctrl: 'l']
- action: [SwitchToMode: RenameTab, TabNameInput: [0]]
key: [Ctrl: 'c']
- action: [ToggleActiveSyncTab]
key: [Ctrl: 's']
- action: [GoToTab: 1]
key: [Ctrl: '1']
- action: [GoToTab: 2]
key: [Ctrl: '2']
- action: [GoToTab: 3]
key: [Ctrl: '3']
- action: [GoToTab: 4]
key: [Ctrl: '4']
- action: [GoToTab: 5]
key: [Ctrl: '5']
- action: [GoToTab: 6]
key: [Ctrl: '6']
- action: [GoToTab: 7]
key: [Ctrl: '7']
- action: [GoToTab: 8]
key: [Ctrl: '8']
- action: [GoToTab: 9]
key: [Ctrl: '9']
# Toggles Mode Actions
- action: [ToggleFocusFullscreen]
key: [Char: 'f']
- action: [TogglePaneFrames]
key: [Char: 'z']
- action: [ToggleFloatingPanes]
key: [Char: 'w']
- action: [TogglePaneEmbedOrFloating]
key: [Char: 'e']
tab:
# Common:
- unbind: true
move:
# Common:
- unbind: true
- action: [ TogglePaneFrames, SwitchToMode: Normal]
key: [ Char: " "]
# Switch Modes
- action: [SwitchToMode: Pane]
key: [Esc]
# Mode Actions
- action: [MovePane: ]
key: [Char: 'n', Char: "\t"]
- action: [MovePane: Left]
key: [Char: 'h', Left]
- action: [MovePane: Down]
key: [Char: 'j', Down]
- action: [MovePane: Up]
key: [Char: 'k', Up,]
- action: [MovePane: Right]
key: [Char: 'l', Right]
renametab:
# Common:
- unbind: true
- action: [ TogglePaneFrames, SwitchToMode: Normal]
key: [ Char: " "]
# Switch Modes
- action: [SwitchToMode: Pane]
key: [Char: "\n"]
- action: [UndoRenameTab , SwitchToMode: Pane]
key: [Esc]
renamepane:
# Common:
- unbind: true
- action: [ TogglePaneFrames, SwitchToMode: Normal]
key: [ Char: " "]
# Switch Modes
- action: [SwitchToMode: Pane]
key: [Char: "\n"]
- action: [UndoRenamePane , SwitchToMode: Pane]
key: [Esc]
resize:
# Common:
- unbind: true
- action: [ TogglePaneFrames, SwitchToMode: Normal]
key: [ Char: " "]
# Switch Modes
- action: [SwitchToMode: Pane]
key: [Esc]
# Mode Actions
- action: [Resize: Left]
key: [Char: 'h', Left]
- action: [Resize: Down]
key: [Char: 'j', Down]
- action: [Resize: Up]
key: [Char: 'k', Up,]
- action: [Resize: Right]
key: [Char: 'l', Right]
- action: [Resize: Increase]
key: [Char: '=', Char: '+', Char: 'i']
- action: [Resize: Decrease]
key: [Char: '-', Char: 'n'] # n for "narrow"
scroll:
# Common:
- unbind: true
- action: [ TogglePaneFrames, SwitchToMode: Normal]
key: [ Char: " "]
# Switch Modes
- action: [ScrollToBottom, SwitchToMode: Pane]
key: [Esc]
- action: [SwitchToMode: EnterSearch, SearchInput: [0]]
key: [Char: '/']
- action: [EditScrollback, SwitchToMode: Normal]
key: [Char: 'e']
# Nav
- action: [ScrollDown]
key: [Char: 'j', Down]
- action: [ScrollUp]
key: [Char: 'k', Up]
- action: [PageScrollDown]
key: [Ctrl: 'f', PageDown, Right, Char: 'l']
- action: [PageScrollUp]
key: [Ctrl: 'b', PageUp, Left, Char: 'h']
- action: [HalfPageScrollDown]
key: [Char: 'd']
- action: [HalfPageScrollUp]
key: [Char: 'u']
entersearch:
# Common:
- unbind: true
- action: [ TogglePaneFrames, SwitchToMode: Normal]
key: [ Char: " "]
# Switch Modes
- action: [SwitchToMode: Search]
key: [Char: "\n"]
- action: [SearchInput: [27], SwitchToMode: Pane]
key: [Esc]
search:
# Common:
- unbind: true
- action: [ TogglePaneFrames, SwitchToMode: Normal]
key: [ Char: " "]
# Switch Modes
- action: [ScrollToBottom, SearchInput: [27], SwitchToMode: Pane]
key: [Esc]
- action: [SwitchToMode: EnterSearch]
key: [Char: '/']
# Nav
- action: [ScrollDown]
key: [Char: 'j', Down]
- action: [ScrollUp]
key: [Char: 'k', Up]
- action: [PageScrollDown]
key: [Ctrl: 'f', PageDown, Right, Char: 'l']
- action: [PageScrollUp]
key: [Ctrl: 'b', PageUp, Left, Char: 'h']
- action: [HalfPageScrollDown]
key: [Char: 'd']
- action: [HalfPageScrollUp]
key: [Char: 'u']
- action: [Search: Down]
key: [Char: 'n']
- action: [Search: Up]
key: [Char: 'N']
# Actions
- action: [SearchToggleOption: CaseSensitivity]
key: [Char: 'c']
- action: [SearchToggleOption: Wrap]
key: [Char: 'w']
- action: [SearchToggleOption: WholeWord]
key: [Char: 'o']
session:
# Common:
- unbind: true
- action: [ TogglePaneFrames, SwitchToMode: Normal]
key: [ Char: " "]
# Switch Modes
- action: [SwitchToMode: Pane]
key: [Esc]
# Actions
- action: [Detach]
key: [Char: 'd'] |
Alternative VIM bindingsI like your proposal, @samholmes, and it inspired me to give this issue a go myself. You can find the keybindings I came up with attached here: zellij_vim.zip As proposed here, it greatly reduces the amount of keybinding collisions and offers all zellij features without having to rely on the Notes on the bindings:
All other zellij input modes are accessible from the
None of these are displayed in the status bar, though. Also, due to overlaps in the keybinding (The cosmetic additions to display keybindings in the status bar), some keybindings (toggle pane frames/floating panes) aren't displayed, either. Workarounds for the current state of zellijThere's only a single one I needed so far! Displaying bindings in the status barAs you will notice, the status bar (as it is currently implemented) is very picky about when it displays a keybinding hint. That is because it matches for sequences of actions exactly, i.e. it will only display the hint for "New" in My workaround for this limitation: Where appropriate I keep the default binding in the config and use a capital letter to display in the status bar, whereas the real command is bound to the non-capitalized letter instead. In the config, it looks like this: - action: [NewPane: , SwitchToMode: Normal,]
key: [Char: 'N',]
- action: [NewPane: ,]
key: [Char: 'n',]So the UI tells me to press Proposal for a solution: In order to avoid touching the status bar code, it would suffice to add a new Thoughts on the keybindings
This maintains all the existing zellij input modes, which is probably helpful for new users to learn how the application works. Also, as stated before, this is needed to display the keybinding hints in the status bar. Since it always stays in the previous mode, one can now chain actions much more nicely. For example, I can now seamlessly create new panes (via Generally I think zellij doesn't need a lot of work (code-wise) to adopt even complex alternative key-binding schemes. However, it would probably be neat if the user were allowed to add/remove custom input modes to their liking. That, however, will take a lot of work to implement, especially in the status bar for displaying custom keybindings. Problems with this keybinding proposalDue to the additional level of indirection, performing certain actions (Such as quickly moving a pane and going back to "Normal" mode) will require at least one additional keystroke, unless the user binds actions they use frequently to custom keys in e.g. "Pane" mode. However, users often finding themselves preparing a layout by hand or renaming panes/tabs in batches will need much less inputs to achieve their goals with this keymap. Also, this being inspired by vim, it is likely rather complicated/not intuitive for most users. However, this is offset to a certain degree by the status bar showing key hints. |
|
Just so stress - while I'm very happy this discussion is going on, whatever we end up going with must be at least (and hopefully more) as discoverable as the current keybinding scheme. IMO this would require a change in the plugin(s) - which means it lies behind some technical debt - but I'm open to being surprised on this one if anyone has good ideas on how to do this without. |
|
@samholmes - I get what you're saying. I do think something like that will help greatly with discoverability, but I think in our context it will be overkill. I don't want the user to have to read so much just to use the tool. The intention in Zellij's UI was that at a quick glance you know exactly what you can do in each mode by reading its tips and in general by looking at the mode names. This has degraded a bit as we added new features, which is why I think we need a new approach. An example I'm toying with is making the modes only applicable to the hjkl/arrows and thus needing much less of them (just pane/tab/move/resize) and then defaulting to the last mode and having some sort of UI-explained toggle that would make this behaviour clear. This sort of approach can be applied to the other actions as well (eg. a secondary "mode-set" of session operations, pane operations, etc. on the second line of the UI where the tips are now). Just a general half-baked idea to give an example of the direction I'm thinking in. |
|
@imsnif When a user has built the muscle-memory for a command, no discoverability is needed not even a subtle one. Only when a user is struggling to remember or is completely new to the tool is discoverability important UX. So, simply hide/show the HUD using |
|
I agree with everything you said up until the last phrase :) For the reasons I mentioned above. |
The user doesn't need to read a lot to use the tool, only when to discover commands of which they are unaware or cannot remember.
A single line doesn't scale for discoverability. A hud will scale for discoverability (especially if it's scrollable; hopefully this wont be necessary though). If you're goal is to have a UI tool for discoverability, then use the right UI tool. If the user is not trying to discover, but then they may either be either "searching" or "using". Of course if they're using, no tips are need, so UI should be gone if its invasive (though the HUD is not all that invasive; leave it up to the user to decide), and this can be handled with I hope that makes sense. EDIT: Case in point, do you read the commands after learning them, or do you learn the commands and then never look at the toolbar? Only for the commands you don't know or cannot remember do you need to look at the toolbar. |
|
Thanks for your thoughts @samholmes - my opinion on this remains as stated. |
|
I think my 2cts can come in this issue (even if I did not read all keybindings proposals): Make Zellij auto lock itself when "certain apps" are loaded/used. Maybe the lock should be different and a This list should be easy to add/remove programs from the user config. Maybe not override the default |
|
I tried out zellij today and this problem is what will prevent me from adopting it. The keybindings overlap too much with my text editor (vim), and some of them are intercepted by the operating system (MacOS makes alt + anything painful to use in a terminal). And the locking mechanism isn't a very good solution. Screen and tmux both use a single command-prefix binding that minimizes overlap with other applications. My opinion is that that should be an available option. |
It is. If you like you can remove all keybindings from the config and just stay with I agree that the defaults should be better, but we do have options. :) |
|
Thank you for the fast response!
OK I can see that the default tmux prefix has some associated functionality, which is nice, but it doesn't solve the main problem, which is that all of the other bindings are still in effect. I didn't create a config file (there's nothing in If this is a simple config change then I will definitely try it out. If it's not a simple "use prefix/tmux mode", then I vote to make it simple that way. |
|
Hey @barrykp - I get what you're saying. My solution suggests unbinding all keys except the tmux ones (that's the quickest way, you can also be more creative if you like). I agree the previous docs left something to be desired though. We've just introduced a new configuration format that makes this much easier and I updated the docs. The TLDR for what you want is to use the default config and do something like: For more info: https://zellij.dev/documentation/keybindings.html Personally, I think this is a significantly inferior experience to the default keybindings with some tweaks to avoid those that collide for you in your workflow, but to each their own :) |
|
Thank you for the explanation (and updating the documentation). It looks like I will have to do an update to take advantage of it. I will give it a try!
This can be a lot of work. My OS (macOS) interferes with some keybindings. My terminal application (iterm) might interfere with some (it might now, but at least I don't have to check). The shell I use (bash) uses emacs-style keybindings (especially important for searching). And my editor is vim. Practically all of the default keybindings collide with something. And finding alternatives isn't easy. Choosing is hard, especially when you can't be sure if some app doesn't use it. Personally, it's easier to remember that the multiplexer occupies exactly one keybinding, than to try and cater for everything I might want to do in a terminal in the config. But it's good to support different options for different preferences. |
|
I am trying to map @samholmes "less' mode to KDL.. How do I bind 'Ctrl+Space'? I've tried the several mappings from here Null control character Also, I found that I had 'Ctrl+Space' on my Mac mapped to "select the previous input source" which changed my keyboard language. I unmapped it, but I can't remember if that was a default or if I added it |
|
In my key_bindings:
- { key: Space, mods: Control, chars: "\x00" } # Ctrl + Space |
|
I've been using revolver mode for zj modals, namely stuff over modal in Anyway, ALT in macos is a real pain, since we've lost cmd in the first place.. |
|
Why not follow Tmux, where every command starts with In my current Vim+Tmux workflow, I can easily switch between Shell and Vim using However, I cannot do the same in Zellij; I have to press Because of this, I did not switch to Zellij, the current classic mode requires too many combos to accomplish something simple. |
Because it is extremely cumbersome. :)
You can get Zellij to behave exactly like tmux with a little bit of config (namely using |
Would it be complicated to provide a config option (e.g. |
|
Just to clarify: Zellij supports the tmux keybindings by default. What we're talking about is disabling all the other keybindings on top of that. That being said, I'm happy to provide this as a config/cli option. If you'd like to open an issue about it, that'll be great. |
|
Yeah I got that. Having a config option for this would be easier and might also reduce support queries; I opened #2125. :) |
@imsnif The tmux keybindings does not work when I'm in |
@imsnif Sorry but where exactly should I put |
|
Hey @wongjiahau , add this configuration at the top of the config file |
|
Hello! Just chiming in after seeing the roadmap :) Please also don't forget non-QWERTY layouts, such as common AZERTY, QWERTZ and their macOS variants 🙏🏻 |
|
FYI if anyone would like a config consistent with the suggestion above, I've put mine here: https://gist.github.com/max-sixty/6be7225ddc0a9cecb7203d5f7fb4c8d3 From the comments at the top: This Zellij config offers a more modal experience than the default. There are very few keybindings in the "modal mode", and we hit The only keybindings in the normal mode are:
|
|
So I skimmed over the options above but it's still unclear to me what the suggested way of using this for macos users is? Is there one recommended config so macOS users can use |
|
Try using Kitty terminal emulator on macOS, you should be able to use Alt keybindings. Although I only tried |
|
Alacritty also supports this with the |
|
This is a piece of my configs which I am so satisfied, these configs perfectly solves some of the painful points for the default keybindings of zellij (at least to me):
Note that I changed all the In this setting, in any mode other than lock mode and normal mode, press You also do not need to enter the lock mode of the zellij to send a real Edit: I made some updates on the escape key codes. (e.g. |
|
I agree, I really think alt keys are the way to go. Most major terminals like Alacritty, WezTerm, iTerm2, & Kitty support it on macOS too. |
The important thing is, you must have the ability to send any key sequence to the tty session running in the zellij session, which also includes the lock mode key. Without this, you can’t lock the zellij session in the inner level zellij session (if you are running the nested zellij session), or if you just want to send the key sequence of the lock mode key to the tty. All of them cause lots of trouble. The "Write" action documented in the zellij config requires some hack to make this possible. It takes me some time to figure out |
|
I'm not sure where 7015 is coming from, but it should be pretty easy to figure out the bytes you need to achieve an input, You need to refer to the ASCII table: https://en.wikipedia.org/wiki/ASCII#Control_code_chart For passing alt keys, we need to use the Escape key, which is 27 in the table. After that, if we want to send g, which has the value of 103, you can use I added |
|
I'm gonna put my keybinds that I've setup here, because I believe they are intuitive and better than the default. They are based on the alt-centric layout under examples. I use WezTerm and I think by default the option key is mapped to Alt. config.kdl |
|
The default |
You can use |
|
While I don't think defaults are all that important for people who use advanced tools like zellij (because they should be smart enough to configure), I still feel like pointing out that Maybe ask MAC users at first run how to deal with it, like use a MAC specific sample config file. |
|
I'm on a Mac and will try to use the following setup:
With this do I have Apart from the keybinding dilemma (on a mac :) ) is this a really nice project. Thank you! |
|
Not sure about all your Mac stuffs, but at least an Alt based setup is possible: https://github.com/zellij-org/zellij/blob/main/example/alt-centered-config.kdl (Take care the file is old and the config may have changed since, prefer to dump the config, see: https://zellij.dev/documentation/configuration) |
|
Thank you @Zykino . I will use alt-centered config as inspiration. |
|
I took the advise from the alt-centered config and ended up with something which worked. The "shared_excerpt" did end up like this: I think an improvement this the Mac keybinding could be to use, what is commonly called as, the "Hyper" key. It is a combination of all the modifier keys. Since all the modifiers keys are rarely (or never) used together, can this "Hyper" key then become another virtual modifier key. There is an app for this https://hyperkey.app . I think a lot of people are using Karabiner Elements for this as well. If it was possible to use a "Hyper" key, then could we leave the "Option" key alone, which I think would be the better long term solution. |
|
it is know zellij and helix have significant conflicting keybindings. Here are a few that I have observed: https://github.com/luccahuguet/zellij?tab=readme-ov-file#keybinding-remaps This repo actually is a set of configs that fix the keybings conflicts (and gives helix a fake sidebar) But nevertheless, it would be nice to have zellij avoid these keys, for enhanced helix-friendliness. Or establish some sort of contract? (helix will use ctrl, zellij will use alt, or something) btw, if you find a conflict not listed in the yazelix repo (the link above), please create a issue reporting it |
|
The issue with only alt+arrows working on macos is strange. I'm glad to find that it's an issue because it's been driving me crazy. I'm using zellij across to macs a macbook pro and an imac. Both are late intel models. Everything works fine on the macbook but the imac refuses to work. I discovered a clue, however. I'm able to ssh into the imac from the macbook and open a zellij session on the remote machine. This allows me to use alt bindings in a session running on the problematic machine. It's like they keyboard built into my macbook is capable of sending different "alt" characters. I've tried a few different terminals and none of their option/alt settings seem to do anything. Does this spark any ideas in anyone? |
While Zellij UI is discoverable as opposed to tmux, tmux feels a bit more faster and its keybindings don't overlap with other tools. The Zellij keybindings can be changed but it involves some efforts. There is even an ongoing discussion [1] to change the default Zellij keybindings. It seems that maintanance on skim is a bit stagnant as the last change was more then a year ago. The skim can be also slower then fzf. Due to above observations, aim of this commit is to replace Zellij and skim with tmux and fzf, respectively. [1] zellij-org/zellij#1399 [2] lotabout/skim#317 Signed-off-by: Hrvoje Varga <hrvoje.varga@gmail.com>
|
this was a captivating conversation!! i'm glad alt maps to option on wezterm out of the box, sounds like i avoided some headaches. also want to weigh in that i am heavily in favor of the status bar over the helix-style the idea of collapsing pane mode and tab mode into the same mode is super appealing ... are there useful edge cases that would prevent this from being a standard in the future? |
|
With version More info here: https://zellij.dev/tutorials/colliding-keybindings/ |
and others
The default Zellij keybindings are great. They allow a modal approach that is discoverable and easy to pick up (especially when combined with the status-bar). However, they have two main downsides:
We should think up and implement a default keybinding scheme that solves both of these issues while still keeping the discoverability and easy-of-use of the current keybindings - even if it involves changing modes around or upending existing app assumptions Zellij has.
To be clear - anything we come up with should still allow the usage of the current scheme as a "classic mode" in order not to break anyone's workflow. We will keep supporting this "classic mode" forever.
The text was updated successfully, but these errors were encountered: