Common hotkeys

[jerrygreen]

By "common hotkeys" I mean hotkeys in MacOS / Linux terminals, maybe even from Chrome / Chromium / Edge. I've just downloaded the terminal, and that's the minimum I noticed that I personally lack:

CTRL + NUMBERS => Switches tab to a selected number
CTRL + PGUP / CTRL + PGDN => Switches tab to a previous one / next one
CTRL + D / CTRL + W => Terminates session / closes a tab
CTRL + T => Creates a new tab with a new session
CTRL + N => Creates a new window with a new session

[DHowett]

We've tried so far to avoid most of the ctrl-only hotkeys because every one of those that we bind by default is not accessible to the actual client application (the important thing running inside terminal.)

To that end, we've bound almost every one of these by default...

• ctrl+shift+numbers - switch to tab number
• ctrl+tab, ctrl+shift+tab - move to previous/next tab
• ctrl+shift+w - close pane, terminate session
  • ctrl+d is actually handled by your shell/kernel line discipline, not your terminal, on linux
  • we've followed the same model here
  • as such, ^D works fine in bash, and can be bound in powershell
• ctrl+shift+t - new tab
• ctrl+shift+n - this should be new window, but it's not until Feature Request: Key binding for "New Window" #1051 lands

Every one of these bindings can be changed in the settings 😄 There's more information in the binding and action documentation.

[jerrygreen]

These weird ctrl+shift combinations for very simple actions, uh... Well, the issue I still see here: it's not convenient: too many buttons for too common actions.

In macOS you have another button for that: cmd, which is neat. In Linux systems, as far as I remember, terminals simply use ctrl button for those (at least one of the most popular Ubuntu and Linux Mint do that, but probably many others), sending ^W, ^T and other similar actions to the client only when you press shift too (so clients still have ability to receive these sometimes important inputs). Settings is a good thing but the most common behavior should have privilege and be set properly in settings initially, imo. Sending ^W action to the client, - is it really common? Meh... Closing a tab, - is it really common? Sure it is!

Idk. I don't care too much, simply wanted to try this new terminal. I see some real good work from Microsoft on VSCode and I thought that's finally some change and Microsoft will make some usable terminal finally too. But turns out I'm still not happy with it, since common hotkeys just don't work. I'm sure every single separate person here does a great job. But somehow, as a whole, you guys managed to make a terminal which is only slightly better than CMD, regardless of huge work. Whose decision was that about these ctrl+shift hotkeys for these common behaviors, do you know? Just to know who's to blame :) Was that you? :)

[DHowett]

Yes, that was me!

I’m not going to brandish credentials for too long, but I bought my first laptop and booted it up into Vista just to reject the EULA (as though it mattered! 😁) before I installed Linux. I’m coming at this from just as many years of experience using Linux as anybody could hope, and I assure you the decisions we make here aren’t made lightly.

We started out by having all the hotkeys bound to control! It turned out that people hated it (during preview 0.1 and 0.2), most especially ^W. In most shells people wanted to use, ^W is back-kill-word or similar. We ended up following gnome-terminal’s lead in using Shift for the terminal-level hotkeys. People hated ^W terminating their running session more than they minded some totally rebindable hotkeys having shift in them.

[DHowett]

But somehow, as a whole, you guys managed to make a terminal which is only slightly better than CMD, regardless of huge work.

And hey, that’s just unkind. Above all, we’re folks who are really passionate about terminals. That’s why we’re all here... so to be told that our work moves the needle only very slightly above something that’s 30 years old because of some hotkeys? That’s rough.

[zadjii-msft]

If you don't like the default keybindings, you're absolutely free to remain them to whatever you like. That's The real goal here, to create a terminal that lets users use it however they beat see fit. To customize it exactly to their own liking. In that process, we've got to pick some reasonable defaults that will work for most users, which we've done as @DHowett describes above. If these don't work for you, please go ahead and change them in your settings.json

[jerrygreen]

We started out by having all the hotkeys bound to control! It turned out that people hated it (during preview 0.1 and 0.2), most especially ^W. In most shells people wanted to use, ^W is back-kill-word or similar

Shit, that's true: in vim this hotkey removes a word. Well, those are some cheeky geeks you tested on, your 0.1 and 0.2 previews. Very few people actively use vim, compared to terminal in overall. Even those who use vim sometimes, use very poor functionality, to make some little changes to a config on a server, and quit it as fast as they can, without much hotkeys (that's me). But I may understand their hate, though...

And hey, that’s just unkind

Yeah, I was a bit rude, with intention, because I didn't like the experience. But I didn't mean to be unkind, that's why I said that you guys, everyone separately does a great job, for sure. And also mentioned that's a huge work, nevertheless. But as these vim users who hated control hotkeys, I hate ctrl+shift hotkeys. We are opposite sides of the spectrum, it seems... Spectrum of hate.

Yeah... Weird. There's no "best solution", it seems. Those are simple little things but they break experience a lot. Though, it's somehow not a problem on macOS with their command button, for both sides (vi-users, and simpler-hotkeys-users). And no settings required.

[KalleOlaviNiemitalo]

I wonder if users would like Windows Terminal to pop up a dialog box asking whether the user prefers Ctrl+letter or Ctrl+Shift+letter key bindings, if started when settings.json does not exist yet.

Personally, I would not like such a dialog box, because it would be an additional hurdle when I delete settings.json before trying to reproduce a bug, and would make it even harder to explain how to make Paste work right in PSReadLine.