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

Feature Request: Add retro Apple II cursor style #21602

New Issue
Closed
opened 2026-01-31 07:49:18 +00:00 by claunia · 2 comments
claunia commented 2026-01-31 07:49:18 +00:00
Owner
Copy Link

Originally created by @PhMajerus on GitHub (Apr 29, 2024).

Description of the new feature/enhancement

Considering Terminal has a Retro terminal effects option, I suspect some people like some nostalgia in their command line experience.
The Cursor shape option has a Vintage style that seems to be based on the original IBM PC and MS-DOS.
Most older personal computers didn't use that style, the Filled box was the most common, but there is one outsider that is still missing in Terminal.

The Apple II used the checkerboard stored in the 0x7F position (delete) of its character set as its cursor.
It is an uncommon checkerboard symbol that has the same size as a mathematical symbol (such as +).
image

It would be nice to have that as an option, for old times' sake.

It wouldn't turn into a huge set of weird legacy cursors to support, because as far as I can tell, only the Tandy/RadioShack is another uncommon system, with something that looks like a top rectangle on the cell below. But I don't know that system enough to be sure.
All the other classic systems I tested use a full block: Commodore PET, C64 and later, Amstrad CPC, MSX, MSX2, MSX2+.

Proposed technical implementation details (optional)

I guess Terminal uses characters as cursors, so we really just need that character and an option in the settings to select it.

It just so happens that Cascadia 2404.23 contains the character we need, it is U+2427 Symbol for delete square checker board form (symbol for delete in the Apple II character set) .

Another solution could be to allow any character to be used with a "custom" cursor that, when selected, also provides a field to specify the character to be used. This would be more flexible but less easy as users would need to know which character to use instead of discovering it in the list of cursors.

image

Can you consider adding that as a cursor option for us old-timers?

Originally created by @PhMajerus on GitHub (Apr 29, 2024). # Description of the new feature/enhancement Considering Terminal has a _Retro terminal effects_ option, I suspect some people like some nostalgia in their command line experience. The _Cursor shape_ option has a `Vintage ` style that seems to be based on the original IBM PC and MS-DOS. Most older personal computers didn't use that style, the `Filled box` was the most common, but there is one outsider that is still missing in Terminal. The Apple II used the checkerboard stored in the `0x7F` position (_delete_) of its character set as its cursor. It is an uncommon checkerboard symbol that has the same size as a mathematical symbol (such as `+`). ![image](https://github.com/microsoft/terminal/assets/25664275/f41bbe13-7696-4491-bafd-a1fa04953fa8) It would be nice to have that as an option, for old times' sake. It wouldn't turn into a huge set of weird legacy cursors to support, because as far as I can tell, only the Tandy/RadioShack is another uncommon system, with something that looks like a top rectangle on the cell below. But I don't know that system enough to be sure. All the other classic systems I tested use a full block: Commodore PET, C64 and later, Amstrad CPC, MSX, MSX2, MSX2+. # Proposed technical implementation details (optional) I guess Terminal uses characters as cursors, so we really just need that character and an option in the settings to select it. It just so happens that Cascadia 2404.23 contains the character we need, it is `U+2427` _Symbol for delete square checker board form (symbol for delete in the Apple II character set)_ . Another solution could be to allow any character to be used with a "custom" cursor that, when selected, also provides a field to specify the character to be used. This would be more flexible but less easy as users would need to know which character to use instead of discovering it in the list of cursors. ![image](https://github.com/microsoft/terminal/assets/25664275/eda4c0f7-b302-47d6-bfc9-0ea873e8ae71) Can you consider adding that as a cursor option for us old-timers?
claunia added the Issue-FeatureArea-RenderingNeeds-Tag-FixProduct-Terminal labels 2026-01-31 07:49:19 +00:00
claunia commented 2026-01-31 07:49:20 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (May 1, 2024):

Our most commonly used cursor "color" is one that inverses the underlying color to always keep it visible:
image

However, there's a problem: If the underlying color is very close to gray (or some equivalent) then the inverse will also be gray which causes the cursor to be invisible. To solve that issue, we compute color distances when drawing the cursor and nudge the cursor and inverted text colors to be further apart. Finally, we also need to stretch the cursor when hovering over a wide glyph and it's unclear how that would look like with this grid shape.

While the 5x5 grid glyph can technically be implemented just like the empty box cursor as a set of rectangles, this one would result in not just 4 but 25 rectangles. Every single one of those would consist of 2 individual triangles during rendering. That's certainly anything but optimal.

The proper solution here would be to draw the glyph into our glyph cache and use it as a pixel-by-pixel lookup texture to invert every underlying pixel where the lookup texture is lit/white. This would need to be implemented in the pixel shader. But there's multiple problems with that:

  • Requires us to port the color distance algorithm to HLSL.
  • Requires us to invert the text at the time it is being blended into the swap chain. This is because text rendering is gamma corrected based on the text color and this information is lost once the blending finished. Inverting the color retroactively leads to either too thin or too fat looking stems in the glyphs.
  • Right now, we upload the pixel shader constant buffer as an immutable buffer, which is quite efficient. This change would require us to turn that into a dynamic buffer because the constant buffer would need to store the changing location of the cursor in the viewport. Graphics drivers may handle dynamic constant buffers by allocating large ring buffers so that they can be efficiently pipelined. We'll have to test all of our relevant hardware on how they react to such a change. After all, we're trying to optimize the renderer for power draw and memory usage, while graphics drivers are always trying to optimize us as if we were a video game. This conflict of interests continues to be an issue for us.

I think rendering cursor in the pixel shader is the right way to do it, no matter what. The importance of this feature VS the time required for testing it is the real issue unfortunately. 😟

@lhecker commented on GitHub (May 1, 2024): Our most commonly used cursor "color" is one that inverses the underlying color to always keep it visible: ![image](https://github.com/microsoft/terminal/assets/2256941/9fa71795-0675-4434-b6c3-0aa8818794e4) However, there's a problem: If the underlying color is very close to gray (or some equivalent) then the inverse will also be gray which causes the cursor to be invisible. To solve that issue, we compute color distances when drawing the cursor and nudge the cursor and inverted text colors to be further apart. Finally, we also need to stretch the cursor when hovering over a wide glyph and it's unclear how that would look like with this grid shape. While the 5x5 grid glyph can technically be implemented just like the empty box cursor as a set of rectangles, this one would result in not just 4 but 25 rectangles. Every single one of those would consist of 2 individual triangles during rendering. That's certainly anything but optimal. The proper solution here would be to draw the glyph into our glyph cache and use it as a pixel-by-pixel lookup texture to invert every underlying pixel where the lookup texture is lit/white. This would need to be implemented in the pixel shader. But there's multiple problems with that: * Requires us to port the color distance algorithm to HLSL. * Requires us to invert the text at the time it is being blended into the swap chain. This is because text rendering is gamma corrected based on the text color and this information is lost once the blending finished. Inverting the color retroactively leads to either too thin or too fat looking stems in the glyphs. * Right now, we upload the pixel shader constant buffer as an immutable buffer, which is quite efficient. This change would require us to turn that into a dynamic buffer because the constant buffer would need to store the changing location of the cursor in the viewport. Graphics drivers may handle dynamic constant buffers by allocating large ring buffers so that they can be efficiently pipelined. We'll have to test all of our relevant hardware on how they react to such a change. After all, we're trying to optimize the renderer for power draw and memory usage, while graphics drivers are always trying to optimize us as if we were a video game. This conflict of interests continues to be an issue for us. I think rendering cursor in the pixel shader is the right way to do it, no matter what. The importance of this feature VS the time required for testing it is the real issue unfortunately. 😟
claunia commented 2026-01-31 07:49:21 +00:00
Author
Owner
Copy Link

@PhMajerus commented on GitHub (May 2, 2024):

@lhecker
Hey, I know that segmented 0! 😉

Thanks for all the details. And yeah, I was hoping it could just be an extra label and character in a list of cursors.
I didn't think about the way you invert the character under the cursor.
On the Apple II, the cursor is not xor-blitted with the character at that position, it simply toggles between the character and the cursor. So I was thinking about that behavior which is basically just changing the character at the cursor position on the blink interval.
The work involved isn't worth it for the nostalgia thrill, and apps can still achieve the same result by swapping the character explicitely.

@PhMajerus commented on GitHub (May 2, 2024): @lhecker Hey, I know that segmented 0! 😉 Thanks for all the details. And yeah, I was hoping it could just be an extra label and character in a list of cursors. I didn't think about the way you invert the character under the cursor. On the Apple II, the cursor is not xor-blitted with the character at that position, it simply toggles between the character and the cursor. So I was thinking about that behavior which is basically just changing the character at the cursor position on the blink interval. The work involved isn't worth it for the nostalgia thrill, and apps can still achieve the same result by swapping the character explicitely.
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-Rendering Issue-Feature Needs-Tag-Fix 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#21602
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?