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

Using Far Manager under Terminal: Command history similar to IntelliSense does not work #5501

New Issue
Closed
opened 2026-01-31 00:14:52 +00:00 by claunia · 12 comments
claunia commented 2026-01-31 00:14:52 +00:00
Owner
Copy Link

Originally created by @safopet on GitHub (Dec 11, 2019).

I like to use Far Manager (64-bit clone of Norton Comander).
https://www.farmanager.com/index.php?l=en
However I can't use very helpful functionality that available if run far manager under simple cmd:
image

Originally created by @safopet on GitHub (Dec 11, 2019). I like to use Far Manager (64-bit clone of Norton Comander). https://www.farmanager.com/index.php?l=en However I can't use very helpful functionality that available if run far manager under simple cmd: ![image](https://user-images.githubusercontent.com/7474952/70601795-ecb53680-1c03-11ea-9021-43d248dbd65c.png)
claunia added the Area-OutputIssue-BugNeeds-Tag-FixProduct-ConptyPriority-2 labels 2026-01-31 00:14:52 +00:00
claunia commented 2026-01-31 00:14:53 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Dec 11, 2019):

Hey thanks for the bug report! Since we're not super familiar with far commander, could yo u help answer a couple questions?

  • What version of the Windows Terminal are you using?
  • What version of Windows are you running?
  • What keys are you pressing to open that dialog?
  • What would you expect to be happening?
@zadjii-msft commented on GitHub (Dec 11, 2019): Hey thanks for the bug report! Since we're not super familiar with far commander, could yo u help answer a couple questions? * What version of the Windows Terminal are you using? * What version of Windows are you running? * What keys are you pressing to open that dialog? * What would you expect to be happening?
claunia commented 2026-01-31 00:14:53 +00:00
Author
Owner
Copy Link

@safopet commented on GitHub (Dec 12, 2019):

What version of the Windows Terminal are you using?

Version: 0.7.3382.0

What version of Windows are you running?

Windows 10 Pro 1909 18363.535 (Russian localization)
Also, I use a latest stable builds of Far Manager: 3.0.0.5511 x64

What keys are you pressing to open that dialog?

I pressed any letter key. When I prepare screen-shot I presss 'y'.

What would you expect to be happening?

I expect showing a list of commands that I recently typed and they begin with pressed letters (a like IntelliSens in Visual Studio) as in screen-shot in my first message:
image
However, Nothing to happened:
image

@safopet commented on GitHub (Dec 12, 2019): > What version of the Windows Terminal are you using? Version: 0.7.3382.0 > What version of Windows are you running? Windows 10 Pro 1909 18363.535 (Russian localization) Also, I use a latest stable builds of Far Manager: 3.0.0.5511 x64 > What keys are you pressing to open that dialog? I pressed any letter key. When I prepare screen-shot I presss 'y'. > What would you expect to be happening? I expect showing a list of commands that I recently typed and they begin with pressed letters (a like IntelliSens in Visual Studio) as in screen-shot in my first message: ![image](https://user-images.githubusercontent.com/7474952/70601795-ecb53680-1c03-11ea-9021-43d248dbd65c.png) However, Nothing to happened: ![image](https://user-images.githubusercontent.com/7474952/70683720-77556e80-1cb4-11ea-806c-56508bacea4d.png)
claunia commented 2026-01-31 00:14:53 +00:00
Author
Owner
Copy Link

@dmytro-boichenko commented on GitHub (Jun 1, 2020):

I fixed that issue just by adding %ProgramFiles%\\Far Manager to local PATH variable

@dmytro-boichenko commented on GitHub (Jun 1, 2020): I fixed that issue just by adding `%ProgramFiles%\\Far Manager` to local `PATH` variable
claunia commented 2026-01-31 00:14:53 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jun 4, 2020):

Just tried that out locally - unfortunately didn't do anything for me 😕. Maybe they're doing something weird like creating another screen buffer? I really have no idea why this would be happening.

@zadjii-msft commented on GitHub (Jun 4, 2020): Just tried that out locally - unfortunately didn't do anything for me 😕. Maybe they're doing something weird like creating another screen buffer? I really have no idea why this would be happening.
claunia commented 2026-01-31 00:14:54 +00:00
Author
Owner
Copy Link

@gabest11 commented on GitHub (Aug 3, 2020):

https://github.com/FarGroup/FarManager/issues/262

@gabest11 commented on GitHub (Aug 3, 2020): https://github.com/FarGroup/FarManager/issues/262
claunia commented 2026-01-31 00:14:54 +00:00
Author
Owner
Copy Link

@alabuzhev commented on GitHub (Aug 3, 2020):

In the linked issue it has been discovered that GetNumberOfConsoleInputEvents API reports 1 under this new terminal and 0 under the default console host after receiving the identical keyboard input.

I think this might be the cause:

Please take this tool - readkey.zip - and do the following under both conhost and terminal:

  • Press any key, e.g. Space
  • Hold it for a while
  • Release it
  • Compare the output.

Conhost:

KEY_EVENT_RECORD: Down, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000020 (casac - ecNs)
KEY_EVENT_RECORD: Down, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000020 (casac - ecNs)
KEY_EVENT_RECORD: Down, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000020 (casac - ecNs)
KEY_EVENT_RECORD: Down, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000020 (casac - ecNs)
KEY_EVENT_RECORD: Down, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000020 (casac - ecNs)
KEY_EVENT_RECORD: Down, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000020 (casac - ecNs)
KEY_EVENT_RECORD: Down, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000020 (casac - ecNs)
KEY_EVENT_RECORD: Up, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000020 (casac - ecNs)

Terminal:

KEY_EVENT_RECORD: Down, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000000 (casac - ecns)
KEY_EVENT_RECORD: Up, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000000 (casac - ecns)
KEY_EVENT_RECORD: Down, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000000 (casac - ecns)
KEY_EVENT_RECORD: Up, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000000 (casac - ecns)
KEY_EVENT_RECORD: Down, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000000 (casac - ecns)
KEY_EVENT_RECORD: Up, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000000 (casac - ecns)
KEY_EVENT_RECORD: Down, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000000 (casac - ecns)
KEY_EVENT_RECORD: Up, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000000 (casac - ecns)
KEY_EVENT_RECORD: Down, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000000 (casac - ecns)
KEY_EVENT_RECORD: Up, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000000 (casac - ecns)
KEY_EVENT_RECORD: Down, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000000 (casac - ecns)
KEY_EVENT_RECORD: Up, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000000 (casac - ecns)
KEY_EVENT_RECORD: Down, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000000 (casac - ecns)
KEY_EVENT_RECORD: Up, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000000 (casac - ecns)

I.e. terminal reports paired false "Up" events even though the key stays down.

If terminal sends the Up event instantaneously after the Down event, and not when I release the key as it should, it's not surprising that the Up is already in the input queue while we're still processing the Down event.

In any case, the current terminal behaviour regarding Up and Down event is:

  • illogical
  • a breaking change.
@alabuzhev commented on GitHub (Aug 3, 2020): In the linked issue it has been discovered that GetNumberOfConsoleInputEvents API reports 1 under this new terminal and 0 under the default console host after receiving the identical keyboard input. I think this might be the cause: Please take this tool - [readkey.zip](https://github.com/FarGroup/FarManager/files/5018508/readkey.zip) - and do the following under both conhost and terminal: - Press any key, e.g. <kbd>Space</kbd> - Hold it for a while - Release it - Compare the output. Conhost: ``` KEY_EVENT_RECORD: Down, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000020 (casac - ecNs) KEY_EVENT_RECORD: Down, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000020 (casac - ecNs) KEY_EVENT_RECORD: Down, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000020 (casac - ecNs) KEY_EVENT_RECORD: Down, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000020 (casac - ecNs) KEY_EVENT_RECORD: Down, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000020 (casac - ecNs) KEY_EVENT_RECORD: Down, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000020 (casac - ecNs) KEY_EVENT_RECORD: Down, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000020 (casac - ecNs) KEY_EVENT_RECORD: Up, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000020 (casac - ecNs) ``` Terminal: ``` KEY_EVENT_RECORD: Down, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000000 (casac - ecns) KEY_EVENT_RECORD: Up, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000000 (casac - ecns) KEY_EVENT_RECORD: Down, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000000 (casac - ecns) KEY_EVENT_RECORD: Up, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000000 (casac - ecns) KEY_EVENT_RECORD: Down, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000000 (casac - ecns) KEY_EVENT_RECORD: Up, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000000 (casac - ecns) KEY_EVENT_RECORD: Down, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000000 (casac - ecns) KEY_EVENT_RECORD: Up, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000000 (casac - ecns) KEY_EVENT_RECORD: Down, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000000 (casac - ecns) KEY_EVENT_RECORD: Up, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000000 (casac - ecns) KEY_EVENT_RECORD: Down, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000000 (casac - ecns) KEY_EVENT_RECORD: Up, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000000 (casac - ecns) KEY_EVENT_RECORD: Down, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000000 (casac - ecns) KEY_EVENT_RECORD: Up, Count=1, Vk=VK_SPACE [32/0x20], Scan=57, uChar=[U=' '(0x0020) A=' '(0x20)], Control=0x00000000 (casac - ecns) ``` I.e. terminal reports paired false "Up" events even though the key stays down. If terminal sends the Up event instantaneously after the Down event, and not when I release the key as it should, it's not surprising that the Up is already in the input queue while we're still processing the Down event. In any case, the current terminal behaviour regarding Up and Down event is: - illogical - a breaking change.
claunia commented 2026-01-31 00:14:54 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Aug 3, 2020):

Discussion moved from FAR-262

You're not wrong about it being a breaking change, but it's a breaking change for clients who should be robust enough to handle it.

The core issue is that there is not a broad standard in use that allows for a VT encoding of make/break sequences. There's no widely-compatible mechanism for communicating a key's press and release separately over SSH (or anywhere VT input is required). The few specifications there are (DECKPM, DECSMKR, DECPCTERM) are not offered by any terminal emulator, and there is a handful of homegrown implementations (libtickit, kitty's make/break extension).

Given that the entire rest of the world settled on key press being the event of repute and chose to discard key release, it's not illogical at all.

@DHowett commented on GitHub (Aug 3, 2020): Discussion moved from FAR-262 --- You're not wrong about it being a breaking change, but it's a breaking change for clients who should be robust enough to handle it. The core issue is that there is not a broad standard in use that allows for a VT encoding of make/break sequences. There's no widely-compatible mechanism for communicating a key's _press_ and _release_ separately over SSH (or anywhere VT input is required). The few specifications there are (DECKPM, DECSMKR, DECPCTERM) are not offered by any terminal emulator, and there is a handful of homegrown implementations (libtickit, kitty's make/break extension). Given that the entire rest of the world settled on key _press_ being the event of repute and chose to discard key _release_, it's not illogical at all.
claunia commented 2026-01-31 00:14:54 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Aug 3, 2020):

We knew going into this that in choosing a naturally less-featureful pipe (by going "all in" on VT for input/output) we'd hit an impedance mismatch for a small percentage of Windows applications. It was a sacrifice we initially made for broader compatibility: trading working with a larger percentage of terminal emulators for losing a smaller percentage of Windows apps.

Internally (to Terminal), we're still unfortunately hampered by our UI framework in determining when a character-generating key was released. We've gotta fake it because that's what we're given.

Externally, we're trying to change the landscape with the spec from #4999, but I can't speak for when other terminal emulators on Windows will follow us in implementing make/break sequences.

@DHowett commented on GitHub (Aug 3, 2020): We knew going into this that in choosing a naturally less-featureful pipe (by going "all in" on VT for input/output) we'd hit an impedance mismatch for a small percentage of Windows applications. It was a sacrifice we initially made for broader compatibility: trading working with a larger percentage of terminal emulators for losing a smaller percentage of Windows apps. Internally (to Terminal), we're still unfortunately hampered by our UI framework in determining when a _character-generating key_ was released. We've gotta fake it because that's what we're given. Externally, we're trying to change the landscape with the spec from #4999, but I can't speak for when other terminal emulators on Windows will follow us in implementing make/break sequences.
claunia commented 2026-01-31 00:14:54 +00:00
Author
Owner
Copy Link

@alabuzhev commented on GitHub (Aug 3, 2020):

@DHowett , thanks for the explanation.
It's a little sad though that more and more native concepts are being sacrificed for VT compatibility.

@alabuzhev commented on GitHub (Aug 3, 2020): @DHowett , thanks for the explanation. It's a little sad though that more and more native concepts are being sacrificed for VT compatibility.
claunia commented 2026-01-31 00:14:55 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Aug 3, 2020):

I agree! We're trying to avoid or repair those sacrifices where possible. 😄

  • make/break events for other terminals to implement
  • Mapping VT mouse input -> win32 mouse input (#376)
  • X10 focus events can be coded in VT, which could help us generate a FOCUS_INPUT_EVENT
  • OSCs that report/set the palette can interact with the traditional conhost color palette

I'd continue listing, but it would rapidly take us off-topic. I don't want to sacrifice the things that made the console infrastructure on Windows good; I'd just like to sacrifice the ones that made it worse.

@DHowett commented on GitHub (Aug 3, 2020): I agree! We're trying to avoid or repair those sacrifices where possible. :smile: * [make/break events](https://github.com/microsoft/terminal/blob/master/doc/specs/%234999%20-%20Improved%20keyboard%20handling%20in%20Conpty.md) for other terminals to implement * Mapping VT mouse input -> win32 mouse input (#376) * X10 focus events can be coded in VT, which could help us generate a `FOCUS_INPUT_EVENT` * OSCs that report/set the palette can interact with the traditional conhost color palette I'd continue listing, but it would rapidly take us off-topic. I don't want to sacrifice the things that made the console infrastructure on Windows _good_; I'd just like to sacrifice the ones that made it worse.
claunia commented 2026-01-31 00:14:55 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 4, 2022):

Hey so I know it's been few years, but I'm playing around with Far 3.0.5888.0 and Terminal 1.12, and this seems fixed to me.
image

This was either fixed by #4999, or a patch on the Far side.

@zadjii-msft commented on GitHub (Jan 4, 2022): Hey so I know it's been few years, but I'm playing around with Far 3.0.5888.0 and Terminal 1.12, and this seems fixed to me. ![image](https://user-images.githubusercontent.com/18356694/148075475-aa7e9048-f6e0-4a16-896f-2aaded758756.png) This was either fixed by #4999, or a patch on the Far side.
claunia commented 2026-01-31 00:14:55 +00:00
Author
Owner
Copy Link

@alabuzhev commented on GitHub (Jan 4, 2022):

@zadjii-msft yes, there's now a workaround for this in Far.

However, it's worth mentioning that WT keyboard handling is still wonky: false "Up" events are still there for most of the keys.
Surprisingly, some do work correctly, e.g. cursor keys, modifiers, PgUp, PgDn, Home, End, Tab, Del, Ins.

@alabuzhev commented on GitHub (Jan 4, 2022): @zadjii-msft yes, there's now a workaround for this in Far. However, it's worth mentioning that WT keyboard handling is still wonky: false "Up" events are still there for most of the keys. Surprisingly, some **do** work correctly, e.g. cursor keys, modifiers, PgUp, PgDn, Home, End, Tab, Del, Ins.
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-Output Issue-Bug Needs-Tag-Fix Priority-2 Product-Conpty
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#5501
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?