starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Make the Windows menu ("alt spacebar") accessible without a mouse in wsl #8053

New Issue
Open
opened 2026-01-31 01:19:38 +00:00 by claunia · 8 comments
claunia commented 2026-01-31 01:19:38 +00:00
Owner
Copy Link

Originally created by @henrik-jensen on GitHub (May 10, 2020).

Description of the new feature/enhancement

Make alt+space or an alternative key combination access the Application context menu in a wsl console.
Edit: This is a feature request for "...the original Windows console host, ...", (which I assume is where the shortcuts are implemented), not the new terminal.
Edit2: In the windows console, ctrl+m activates the select/copy feature and ctrl+f the find menu (danish and english versions). These are only accessible through the "alt+space"-menu (rodent menu) in a WSL session . Adding an alternative to these in Windows Console for WSL would be a super deluxe bonus value productivity enhancement.

Pressing alt+spacebar opens this menu on common windows apps:
AppContextMenu

In the good old Windows Console/Terminal, as well as most windows app you have access to the (I think it's called?) application context menu, through alt+space without using the mouse. In WSL this does not work. We've got the ctrl+shift+c/v shortcut workarounds to paste/copy. A similar shortcut workaround for alt+space would be much appreciated for those with rodent allergy.

Proposed technical implementation details (optional)

<!-- 
A clear and concise description of what you want to happen.
-->

I have no idea how to implement it but I really would like a relief for my carpal tunnel syndrome :-)

Originally created by @henrik-jensen on GitHub (May 10, 2020). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> # Description of the new feature/enhancement Make alt+space or an alternative key combination access the Application context menu in a wsl console. Edit: This is a feature request for "...the original Windows console host, ...", (which I assume is where the shortcuts are implemented), not the new terminal. Edit2: In the windows console, ctrl+m activates the select/copy feature and ctrl+f the find menu (danish and english versions). These are only accessible through the "alt+space"-menu (rodent menu) in a WSL session . Adding an alternative to these in Windows Console for WSL would be a super deluxe bonus value productivity enhancement. *Pressing alt+spacebar opens this menu on common windows apps:* ![AppContextMenu](https://user-images.githubusercontent.com/9413242/81510888-9c0e4a80-9315-11ea-84a0-d07e21538704.png) <!-- A clear and concise description of what the problem is that the new feature would solve. Describe why and how a user would use this new functionality (if applicable). --> In the good old Windows Console/Terminal, as well as most windows app you have access to the (I think it's called?) application context menu, through alt+space without using the mouse. In WSL this does not work. We've got the ctrl+shift+c/v shortcut workarounds to paste/copy. A similar shortcut workaround for alt+space would be much appreciated for those with rodent allergy. # Proposed technical implementation details (optional) ``` <!-- A clear and concise description of what you want to happen. --> ``` I have no idea how to implement it but I really would like a relief for my carpal tunnel syndrome :-)
claunia added the Help WantedProduct-ConhostIssue-TaskArea-UserInterface labels 2026-01-31 01:19:39 +00:00
claunia commented 2026-01-31 01:19:39 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (May 15, 2020):

You know, I was ready to say that this wouldn't be possible because we wanted to send alt+space to the connected application. We do, we absolutely do, but perhaps alt+shift+space (which doesn't have a VT encoding(!)) could pop up the system menu.

@DHowett-MSFT commented on GitHub (May 15, 2020): You know, I was ready to say that this wouldn't be possible because we wanted to send <kbd>alt+space</kbd> to the connected application. We do, we absolutely do, but perhaps <kbd>alt+shift+space</kbd> (which doesn't have a VT encoding(!)) could pop up the system menu.
claunia commented 2026-01-31 01:19:39 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (May 15, 2020):

fwiw: alt+space in Windows Terminal (instead of the traditional console host) actually does open the system menu. It doesn't let you use any of the actions the console does, but hey, precedent.

@DHowett-MSFT commented on GitHub (May 15, 2020): fwiw: alt+space in Windows Terminal (instead of the traditional console host) actually does open the system menu. It doesn't let you use any of the actions the console does, but hey, precedent.
claunia commented 2026-01-31 01:19:39 +00:00
Author
Owner
Copy Link

@henrik-jensen commented on GitHub (May 15, 2020):

You know, I was ready to say that this wouldn't be possible because we wanted to send alt+space to the connected application. We do, we absolutely do, but perhaps alt+shift+space (which doesn't have a VT encoding(!)) could pop up the system menu.

alt+shift+space would be just fine for the old console host.
ctrl+shift+c/v works in both Windows Terminal and Old Console Host, running wsl, but ctrl+shift+c seams kind of useless without ctrl+m for coping. (You have to use the mouse anyway so you just click right mouse button after select).
How about ctrl+shift+m for select mode. Would that be possible? (for old and new)
And ctrl+shift+a (select all), ctrl+shift+f (find) to mirror the Console Host shortcuts in a cmd-session like the copy/paste does?
All these of course preferably optional as the ctrl+shift+c/v's are.
Edit:
After reconsidering - all these shortcuts are probably used in emacs, vi and lots of other console aps, (just think of the drama :-) ), so ... could/should the alt+space menu with an edit submenu be implemented in the the new Windows Terminal? (I mean alt+space is already taken so it won't result in the sudden end of the editor war and the start of an unholy alliance of emacs and vim users against Windows Terminal :-) )

@henrik-jensen commented on GitHub (May 15, 2020): > You know, I was ready to say that this wouldn't be possible because we wanted to send alt+space to the connected application. We do, we absolutely do, but perhaps alt+shift+space (which doesn't have a VT encoding(!)) could pop up the system menu. alt+shift+space would be just fine for the old console host. ctrl+shift+c/v works in both Windows Terminal and Old Console Host, running wsl, but ctrl+shift+c seams kind of useless without ctrl+m for coping. (You have to use the mouse anyway so you just click right mouse button after select). How about ctrl+shift+m for select mode. Would that be possible? (for old and new) And ctrl+shift+a (select all), ctrl+shift+f (find) to mirror the Console Host shortcuts in a cmd-session like the copy/paste does? All these of course preferably optional as the ctrl+shift+c/v's are. Edit: After reconsidering - all these shortcuts are probably used in emacs, vi and lots of other console aps, (just think of the drama :-) ), so ... could/should the alt+space menu with an edit submenu be implemented in the the new Windows Terminal? (I mean alt+space is already taken so it won't result in the sudden end of the [editor war](https://en.wikipedia.org/wiki/Editor_war) and the start of an unholy alliance of emacs and vim users against Windows Terminal :-) )
claunia commented 2026-01-31 01:19:40 +00:00
Author
Owner
Copy Link

@Neurrone commented on GitHub (May 16, 2020):

I'm not sure if this is related, but I'm having trouble figuring out how to view the tabs open or open dialogs like the settings and help dialog. They don't appear as options when pressing alt+space.

@Neurrone commented on GitHub (May 16, 2020): I'm not sure if this is related, but I'm having trouble figuring out how to view the tabs open or open dialogs like the settings and help dialog. They don't appear as options when pressing alt+space.
claunia commented 2026-01-31 01:19:40 +00:00
Author
Owner
Copy Link

@Neurrone commented on GitHub (May 16, 2020):

Oh, I just realized that the whole row of controls at the top to switch between tabs can only gain keyboard focus when clicking with a mouse :(

@Neurrone commented on GitHub (May 16, 2020): Oh, I just realized that the whole row of controls at the top to switch between tabs can only gain keyboard focus when clicking with a mouse :(
claunia commented 2026-01-31 01:19:40 +00:00
Author
Owner
Copy Link

@binki commented on GitHub (Jun 22, 2020):

You know, I was ready to say that this wouldn't be possible because we wanted to send alt+space to the connected application. We do, we absolutely do, but perhaps alt+shift+space (which doesn't have a VT encoding(!)) could pop up the system menu.

Thanks, didn’t know about this shortcut. It actually works in normal applications already. Somehow, MSYS2 in its latest version turns off using alt+space to open the system menu when run from within CMD but it doesn’t trap alt+shift+space. I will be using this combination everywhere from now on!

@binki commented on GitHub (Jun 22, 2020): > You know, I was ready to say that this wouldn't be possible because we wanted to send alt+space to the connected application. We do, we absolutely do, but perhaps alt+shift+space (which doesn't have a VT encoding(!)) could pop up the system menu. Thanks, didn’t know about this shortcut. It actually works in normal applications already. Somehow, MSYS2 in its latest version turns off using alt+space to open the system menu when run from within CMD but it doesn’t trap alt+shift+space. I will be using this combination everywhere from now on!
claunia commented 2026-01-31 01:19:40 +00:00
Author
Owner
Copy Link

@dobsa commented on GitHub (Apr 6, 2022):

I consider Alt+Space standard combination since it works across application types in Windows for decades (For example also in GUI applications). There absolutely must be a possibility to configure Alt+Space to be used for Window management. Again most commonly used SSH GUI client out there -- PuTTY -- has this option for decades. Alt+Shift+Space would be a lame workaround. Configuration option for this is needed. What is particularly annoying is that Alt+Space works in cmd.exe. But as soon as I connect to a Linux server using Microsoft's port of OpenSSH it stops working and it cannot be configured. If it can, please tell me how.

@dobsa commented on GitHub (Apr 6, 2022): I consider Alt+Space standard combination since it works across application types in Windows for decades (For example also in GUI applications). There absolutely must be a possibility to configure Alt+Space to be used for Window management. Again most commonly used SSH GUI client out there -- PuTTY -- has this option for decades. Alt+Shift+Space would be a lame workaround. Configuration option for this is needed. What is particularly annoying is that Alt+Space works in cmd.exe. But as soon as I connect to a Linux server using Microsoft's port of OpenSSH it stops working and it cannot be configured. If it can, please tell me how.
claunia commented 2026-01-31 01:19:40 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Apr 6, 2022):

FWIW this is totally configurable in the Terminal, and works even in WSL. It's just conhost (the vintage console) where this is an issue. The keybindings in cohost have always been a source of constant pain, just the way they're plumbed through makes thinks like this REALLY HARD to solve. We also definitely don't have any plans to fix this for conhost any time soon - we're not really specifically investing in that UX any longer.

I'm gonna leave this open if someone does want to add alt+shift+space to conhost. But if you want real configurability, I'd just recommend the Terminal.

@zadjii-msft commented on GitHub (Apr 6, 2022): FWIW this is totally configurable in the Terminal, and works even in WSL. It's just conhost (the vintage console) where this is an issue. The keybindings in cohost have always been a source of constant pain, just the way they're plumbed through makes thinks like this REALLY HARD to solve. We also definitely don't have any plans to fix this for conhost any time soon - we're not really specifically investing in that UX any longer. I'm gonna leave this open if someone does want to add <kbd>alt+shift+space</kbd> to conhost. But if you want real configurability, I'd just recommend the Terminal.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-UserInterface Help Wanted Issue-Task Product-Conhost
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#8053
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?