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

Feature Request: /help commands output to collapsible pane #915

New Issue
Open
opened 2026-01-30 22:10:13 +00:00 by claunia · 10 comments
claunia commented 2026-01-30 22:10:13 +00:00
Owner
Copy Link

Originally created by @mdtauk on GitHub (May 9, 2019).

When using command line tools, I often have to continuously repeat typing command /help to remind myself what I can do with the app.

If there was a way to output the text displayed when typing /help to a collapse box on the screen, I could then expand it to find a command, without having to keep either scrolling, or re-running the command

Originally created by @mdtauk on GitHub (May 9, 2019). When using command line tools, I often have to continuously repeat typing command /help to remind myself what I can do with the app. If there was a way to output the text displayed when typing /help to a collapse box on the screen, I could then expand it to find a command, without having to keep either scrolling, or re-running the command
claunia commented 2026-01-30 22:10:14 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (May 9, 2019):

Maybe it could be a cool differentiating feature to be able to select a region and pin it (or pull it out)?

@DHowett-MSFT commented on GitHub (May 9, 2019): Maybe it could be a cool differentiating feature to be able to _select a region and pin it_ (or pull it out)?
claunia commented 2026-01-30 22:10:14 +00:00
Author
Owner
Copy Link

@mdtauk commented on GitHub (May 9, 2019):

Maybe introduce the concept of Terminal specific commands. Maybe
Command.exe /help #region

Which will place any output from that command into a side pane

@mdtauk commented on GitHub (May 9, 2019): Maybe introduce the concept of Terminal specific commands. Maybe ` Command.exe /help #region ` Which will place any output from that command into a side pane
claunia commented 2026-01-30 22:10:14 +00:00
Author
Owner
Copy Link

@binarycrusader commented on GitHub (May 9, 2019):

Named pipes would be ideal here I think, but if I recall correctly there are restrictions around UWP apps and pipes. Something like:

program.exe /help >\\.\pipe\terminal_region_name

The unc syntax is unfortunate, but it would be more generic and helpful and reuse the existing cmd mechanisms.

If I recall correctly, the restriction on named pipes with uwp apps is that you can do that between two uwp apps or two non-uwp apps, so maybe this will work?

@binarycrusader commented on GitHub (May 9, 2019): Named pipes would be ideal here I think, but if I recall correctly there are restrictions around UWP apps and pipes. Something like: `program.exe /help >\\.\pipe\terminal_region_name` The unc syntax is unfortunate, but it would be more generic and helpful and reuse the existing cmd mechanisms. If I recall correctly, the restriction on named pipes with uwp apps is that you can do that between two uwp apps or two non-uwp apps, so maybe this will work?
claunia commented 2026-01-30 22:10:15 +00:00
Author
Owner
Copy Link

@mdtauk commented on GitHub (May 9, 2019):

Not sure if it is possible to choose some kind of syntax that would be ignored by the existing command line, but recognised by the Windows Terminal. Just in case a batch script leaves it in when shared online

@mdtauk commented on GitHub (May 9, 2019): Not sure if it is possible to choose some kind of syntax that would be ignored by the existing command line, but recognised by the Windows Terminal. Just in case a batch script leaves it in when shared online
claunia commented 2026-01-30 22:10:15 +00:00
Author
Owner
Copy Link

@oising commented on GitHub (May 9, 2019):

Maybe it could be a cool differentiating feature to be able to select a region and pin it (or pull it out)?

I think this is probably the only reasonable suggestion here. Using Windows named pipes ties shell scripts to a specific terminal, and specifically a Windows-only terminal. It's often tough enough to get scripts to work on the same family of shells :) The same goes for using meta keywords like #region or something. @DHowett-MSFT 's suggestion doesn't tie the script to the terminal implementation, so it's the only sane one.

@oising commented on GitHub (May 9, 2019): > Maybe it could be a cool differentiating feature to be able to _select a region and pin it_ (or pull it out)? I think this is probably the only reasonable suggestion here. Using Windows named pipes ties shell scripts to a specific terminal, and specifically a Windows-only terminal. It's often tough enough to get scripts to work on the same family of shells :) The same goes for using meta keywords like #region or something. @DHowett-MSFT 's suggestion doesn't tie the _script_ to the terminal implementation, so it's the only sane one.
claunia commented 2026-01-30 22:10:15 +00:00
Author
Owner
Copy Link

@mdtauk commented on GitHub (May 10, 2019):

If doing it as part of the typed command is a no go, then perhaps the ability to pin or drag output into a side pane. Perhaps with a pin icon beside the outputted text or via a context menu?

Long output and having to select all the lines could be cumbersome

@mdtauk commented on GitHub (May 10, 2019): If doing it as part of the typed command is a no go, then perhaps the ability to pin or drag output into a side pane. Perhaps with a pin icon beside the outputted text or via a context menu? Long output and having to select all the lines could be cumbersome
claunia commented 2026-01-30 22:10:15 +00:00
Author
Owner
Copy Link

@binarycrusader commented on GitHub (May 10, 2019):

It all depends on what the goal is. If the goal is to redirect output in a dynamic fashion, then pipes, etc. are the only portable way that I can think of offhand to do that through a shell, and people coming from a *NIX background are used to that model.

If the goal is to simply create a collection of content for easy reference, then the "snip" and "pin" model might work quite nicely.

@binarycrusader commented on GitHub (May 10, 2019): It all depends on what the goal is. If the goal is to redirect output in a dynamic fashion, then pipes, etc. are the only portable way that I can think of offhand to do that through a shell, and people coming from a *NIX background are used to that model. If the goal is to simply create a collection of content for easy reference, then the "snip" and "pin" model might work quite nicely.
claunia commented 2026-01-30 22:10:15 +00:00
Author
Owner
Copy Link

@binarycrusader commented on GitHub (May 10, 2019):

Using Windows named pipes ties shell scripts to a specific terminal, and specifically a Windows-only terminal. It's often tough enough to get scripts to work on the same family of shells :)

Using named pipes shouldn't tie scripts to a specific terminal or a Windows-only terminal -- *NIX systems have those too, but I'm sure I'm just misunderstanding what the concern being expressed here is. The pipes concept is fairly universal in the developer world so it would be helpful to better understand the concern. The *NIX philosophy very much gravitates towards files. "snip" & "pin" vs redirection both have tradeoffs in opposite directions.

@binarycrusader commented on GitHub (May 10, 2019): > Using Windows named pipes ties shell scripts to a specific terminal, and specifically a Windows-only terminal. It's often tough enough to get scripts to work on the same family of shells :) Using named pipes shouldn't tie scripts to a specific terminal or a Windows-only terminal -- *NIX systems have those too, but I'm sure I'm just misunderstanding what the concern being expressed here is. The pipes concept is fairly universal in the developer world so it would be helpful to better understand the concern. The *NIX philosophy very much gravitates towards files. "snip" & "pin" vs redirection both have tradeoffs in opposite directions.
claunia commented 2026-01-30 22:10:15 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 10, 2019):

For the record, Windows Terminal is a normal win32 application that's using UWP UI elements via XAML Islands. So named pipes aren't going to have the same problems for us that other UWP apps might have.

I really do like this idea of pinning a region of output. Maybe we could store all the pinned blobs you have, and open a new pane on the side to display your pins?

As far as doing it on the commandline, maybe we add support for man ping > wt.exe --pin or something. That way it can be shell-agnostic

@zadjii-msft commented on GitHub (May 10, 2019): For the record, Windows Terminal is a normal win32 application that's using UWP UI elements via XAML Islands. So named pipes aren't going to have the same problems for us that other UWP apps might have. I really do like this idea of pinning a region of output. Maybe we could store all the pinned blobs you have, and open a new pane on the side to display your pins? As far as doing it on the commandline, maybe we add support for `man ping > wt.exe --pin` or something. That way it can be shell-agnostic
claunia commented 2026-01-30 22:10:16 +00:00
Author
Owner
Copy Link

@mdtauk commented on GitHub (May 10, 2019):

So if there is merit in the idea of pinning outputs or snippits to a collapsible side pane, it is about how this is done, and what might you be able to do with the snippits once they are copied to this side pane.

  • Maybe you can click/tap on these snippits to insert them?

  • Maybe you can copy and paste a series of commands to this side pane, and then insert them with a tap?

  • Maybe you can export the side pane contents?

  • Do they appear like the sticky notes list? (without the time stamps and sticky note styling)
    image

  • Is it a single pane shared by all consoles, or one pane per console? (I am in favour of one per console to avoid confusion of formatting and Linux commands used in Console etc)

@mdtauk commented on GitHub (May 10, 2019): So if there is merit in the idea of pinning outputs or snippits to a collapsible side pane, it is about how this is done, and what might you be able to do with the snippits once they are copied to this side pane. - Maybe you can click/tap on these snippits to insert them? - Maybe you can copy and paste a series of commands to this side pane, and then insert them with a tap? - Maybe you can export the side pane contents? - Do they appear like the sticky notes list? (without the time stamps and sticky note styling) ![image](https://user-images.githubusercontent.com/7389110/57560687-7c011f80-737f-11e9-98e6-8b82b6736ed9.png) - Is it a single pane shared by all consoles, or one pane per console? (I am in favour of one per console to avoid confusion of formatting and Linux commands used in Console etc)
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-Extensibility Area-UserInterface Issue-Feature Product-Terminal
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#915
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?