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

New keybindings #143

Merged
merged 7 commits into from
Jul 11, 2019
Merged

New keybindings #143

merged 7 commits into from
Jul 11, 2019

Conversation

raboof
Copy link
Owner

@raboof raboof commented Jul 1, 2019

etc/cfg_bindings.lua Outdated Show resolved Hide resolved
etc/cfg_bindings.lua Outdated Show resolved Hide resolved
kpress(META.."S", "WFrame.switch_nth(_, 1)"),
kpress(META.."D", "WFrame.switch_nth(_, 2)"),
kpress(META.."F", "WFrame.switch_nth(_, 3)"),

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about META..[F1…F9] to change workspaces and META..[1…9] to change client windows (or the other way around because changing workspaces is probably used more often and thus should be closer to the home row)?

Copy link
Owner Author

@raboof raboof Jul 2, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The general concept is:

  • META..[Esc,F1...F9] switches screens
  • META..[`,1..9] switches workspace within a screen
  • META..[Tab-Q] switches between tiles
  • META..[CapsLocak,A-F] switches between tabs within a tile

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I usually have less than 10 screens but more than 5 tabs. F1…12 is a second range of consecutive number keys, I'd say it would be best to use them as such, with everything else on the keyboard being random letters, some of which we might want to use as a mnemonic (the way vim does, "o"=open, "a"=append etc.), which makes it complicated to allocate let's say the whole Q…P row for tab 1…n (besides, those keys are usually shuffled around pseudorandomly in a non-US-keymap).

After all, the keyboard layout is the first thing a new user sees about notion, so I feel it should be as memorable as possible in order to make it easy to get going (this is why I'm proposing "A" for "attach" again).

I'm also a bit conflicted about the META.."K" submap in general, it seems this was used as a place for everything that didn't fit anywhere else (like C-x in emacs), and does not have any meaning? I think it would make more sense to have submaps (if we're going to have any at all in the new keybinding setup) to operate on a type of object, like tabs, e.g. all tab keybindings in META.."T", all workspace keybindings in META.."W", all "go to window by property" (urgent or title) in META.."G" and so on?

Just my two cents, feel free to do something else entirely ;)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe META.."`" could be the submap for whatever object is going to be on META..[0…9] (workspaces)
and META.."Escape" could be the submap for whatever object is going to be on META..[F1…F12] (screens or windows?)

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just my two cents, feel free to do something else entirely ;)

Thanks! I really value the discussion, even though I've been experimenting with this for a while so there are some concepts that I'm reluctant to change :)

the keyboard layout is the first thing a new user sees about notion, so I feel it should be as memorable as possible in order to make it easy to get going

I agree (I wonder if some companion app like #112 could help here, too)

everything else on the keyboard being random letters

Part of idea behind this binding is that all basic 'direct' keys are at the left hand (navigation, fullscreen, scratchpad, etc), and more rarely used keys (e.g. anything that opens a query) are at the right hand. I think this would greatly improve how memorable the keys are. I agree using mnemonics is a useful tool as well, but I think that should be a secondary concern.

some of which we might want to use as a mnemonic (the way vim does, "o"=open, "a"=append etc.)

vim is a bit of an unfortunate example, with hjkl having special meaning there :)

those keys are usually shuffled around pseudorandomly in a non-US-keymap

This is definitely a downside, but I think we should just leave it up to the community to come up with bindings for use with different keymaps.

I'm also a bit conflicted about the META.."K" submap in general

I'm not a fan either. I wonder if we could get away with putting everything under META and META+Shift and drop META+K entirely.

Copy link
Owner Author

@raboof raboof Jul 2, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe META.."`" could be the submap for whatever object is going to be on META..[0…9] (workspaces)
and META.."Escape" could be the submap for whatever object is going to be on META..[F1…F12] (screens or windows?)

For those I had in mind 'next' (so META+Escape=next screen, META+`=next ws, META+Tab=next frame, META+CapsLock=next tab)

Copy link
Collaborator

@wilhelmy wilhelmy Jul 2, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! I really value the discussion, even though I've been experimenting with this for a while so there are some concepts that I'm reluctant to change :)

I understand. I'm most likely not going to use this new setup (except for parts that I like more than what we had in my own modified version of the notion3 standard keymap) because I don't like changing my habits for no good reason, but I think new users should have it easy. If you think you have that figured out, I'm not going to cause you some bikeshed discussion about it.

I agree (I wonder if some companion app like #112 could help here, too)

I think so. vimtutor helped me getting started with vim, at least. This would be very easy to integrate into notion on first start thanks to the lua interface. "Would you like to try the tutorial mode? (y/n)".

Part of idea behind this binding is that all basic 'direct' keys are at the left hand (navigation, fullscreen, scratchpad, etc), and more rarely used keys (e.g. anything that opens a query) are at the right hand. I think this would greatly improve how memorable the keys are. I agree using mnemonics is a useful tool as well, but I think that should be a secondary concern.

I'm inclined to say that mnemonics and similarity to other tools (something that old-school *nix generally does rather badly compared to, say, OS X) help me more than anything else getting used to another keyboard-driven program with a very full keymap. (YMMV and actually I'd be interested in what helps you personally grok a new tool.)

vim is a bit of an unfortunate example, with hjkl having special meaning there :)

Back in the day computers did not have arrow keys (and we had to walk uphill to school both ways—kidding, I'm not old enough to have witnessed this).

Other than hjkl, vi's keyboard layout mostly makes sense imo, and is a good example for keyboard-driven software (albeit taking some time getting used to), perhaps because it has had some level of influence on the rest of the *nix software ecosystem over the decades.

For those I had in mind 'next' (so META+Escape=next screen, META+`=next ws, META+Tab=next frame, META+CapsLock=next tab)

Makes sense this way as well.

I trust you to make the right decisions, and maybe there isn't much value in "adding my own mustard" as we say here.

etc/cfg_bindings.lua Show resolved Hide resolved
etc/cfg_bindings.lua Show resolved Hide resolved
etc/cfg_bindings.lua Show resolved Hide resolved
mpress("Button2", "mod_menu.pmenu(_, _sub, 'windowlist')"),

bdoc("Forward-circulate focus."),
-- '_chld' used here stands to for an actual child window that may not
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think a link to the documentation for _chld, _sub and _ in the context of keybinding config would be really helpful here.

- Free up Escape for 'next screen'
- Use 'W' for 'Frame Down'
- Use 'Q' for fullscreen (for now)
- Use 'P' for 'attach' ('nick')
- Use 'X' for 'unsplit'
@raboof
Copy link
Owner Author

raboof commented Jul 3, 2019

TODO: make sure ALTMETA defaults to META+Shift when it is set to the empty string.

kpress(META.."F3", "ioncore.goto_nth_screen(2)"),
kpress(META.."Shift+4", "ioncore.goto_nth_screen(3)"),
-- kpress(META.."F4", "ioncore.goto_nth_screen(3)"),

bdoc("Go to next/previous screen on multihead setup."),
kpress(ALTMETA.."Escape", "ioncore.goto_prev_screen()"),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In WMoveResize mode, AnyModifier+Escape is bound to cancel resizing.. Does this still work if (ALT)META.."Escape" is bound to switch screens?

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it does look like it (but I don't have a second monitor handy to really test this right now)

@raboof raboof marked this pull request as ready for review July 9, 2019 18:11
@raboof raboof changed the title Initial WiP on new keybindings New keybindings Jul 9, 2019
@raboof
Copy link
Owner Author

raboof commented Jul 9, 2019

I think this is ready for final review/merge, with further evolution be done as subsequent PR's.

@raboof raboof requested review from knixeur and wilhelmy July 11, 2019 16:27
@knixeur
Copy link
Collaborator

knixeur commented Jul 11, 2019

LGTM

@raboof raboof merged commit a1045c5 into master Jul 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants