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

Spellcheck Linting #15477

New Issue
Closed
opened 2026-01-31 04:39:42 +00:00 by claunia · 6 comments
claunia commented 2026-01-31 04:39:42 +00:00
Owner
Copy Link

Originally created by @ZeroCoolGOS on GitHub (Oct 7, 2021).

Description of the new feature/enhancement

It would be nice to have spellcheck linting in terminal. I have had way to many times miss spelled something in terminal, an I have to do spellcheck in Word just to make sure I did not spell something incorrect. Mainly with GIT commits.

Proposed technical implementation details (optional)

Just how Word or Edge flags spelling with the underscore squiggle. If it's possible to have right click correction that would be a bonus.

Originally created by @ZeroCoolGOS on GitHub (Oct 7, 2021). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 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 It would be nice to have spellcheck linting in terminal. I have had way to many times miss spelled something in terminal, an I have to do spellcheck in Word just to make sure I did not spell something incorrect. Mainly with GIT commits. # Proposed technical implementation details (optional) Just how Word or Edge flags spelling with the underscore squiggle. If it's possible to have right click correction that would be a bonus.
claunia added the Issue-FeatureNeeds-TriageNeeds-Tag-FixResolution-Won't-Fix labels 2026-01-31 04:39:42 +00:00
claunia commented 2026-01-31 04:39:43 +00:00
Author
Owner
Copy Link

@WSLUser commented on GitHub (Oct 8, 2021):

Sounds like a good extension. Maybe @jsoref may have ideas on how to do it since he does it for CI which WT uses.

@WSLUser commented on GitHub (Oct 8, 2021): Sounds like a good extension. Maybe @jsoref may have ideas on how to do it since he does it for CI which WT uses.
claunia commented 2026-01-31 04:39:43 +00:00
Author
Owner
Copy Link

@jsoref commented on GitHub (Oct 8, 2021):

Fwiw, VSCode appears to use a similar algorithm to me (I haven't checked their implementation, but based on how it handles things), and we both have settled on the same cspell dictionary sources.

You probably will want the same general ideas I'm using, namely:

  1. a context aware thing to decide to skip entirely -- this might be "ignore everything when the current working directory matches" -- https://github.com/check-spelling/check-spelling/wiki/Configuration-Examples:-excludes
  2. a grammar parser to know when to apply things (check-spelling is very simplistic and applies one ruleset to everything, but, in theory you could want different rules for arguments, or something) -- the naive implementation (as I do) is a regular expression, and the lazy approach (which I also do) is to effectively ignore any content that matches them. -- https://github.com/check-spelling/check-spelling/wiki/Configuration-Examples:-patterns
  3. a base dictionary, the ability to maintain a custom dictionary -- https://github.com/check-spelling/check-spelling/wiki/Feature:-Allow, and possibly the ability to import additional dictionaries -- https://github.com/check-spelling/check-spelling/wiki/Feature:-Area-dictionaries
  4. a base rule for determining what might be words -- currently that's roughly [a-zA-Z']{3,x} -- see https://github.com/check-spelling/check-spelling/wiki/Feature:-Autodetect-valid-word-lengths (fwiw, I'm working on relaxing this rule, and hope to be able to support non-English languages at least by the end of 2022, but hopefully considerably sooner)
  5. a way to recognize jumbled words -- currently, that's roughly https://github.com/check-spelling/check-spelling/blob/prerelease/lib/CheckSpelling/UnknownWordSplitter.pm#L139-L156 (I've only recently started refactoring this, and eventually would hope to have been able to point to test coverage, but, for now, code is king, but the general goal is https://www.check-spelling.dev/#programmer-friendly).

The reporting (squiggles) is left entirely as a problem for the implementer.

@jsoref commented on GitHub (Oct 8, 2021): Fwiw, VSCode appears to use a similar algorithm to me (I haven't checked their implementation, but based on how it handles things), and we both have settled on the same cspell dictionary sources. You probably will want the same general ideas I'm using, namely: 1. a context aware thing to decide to skip entirely -- this might be "ignore everything when the current working directory matches" -- https://github.com/check-spelling/check-spelling/wiki/Configuration-Examples:-excludes 2. a grammar parser to know when to apply things (check-spelling is very simplistic and applies one ruleset to everything, but, in theory you could want different rules for arguments, or something) -- the naive implementation (as I do) is a regular expression, and the lazy approach (which I also do) is to effectively ignore any content that matches them. -- https://github.com/check-spelling/check-spelling/wiki/Configuration-Examples:-patterns 3. a base dictionary, the ability to maintain a custom dictionary -- https://github.com/check-spelling/check-spelling/wiki/Feature:-Allow, and possibly the ability to import additional dictionaries -- https://github.com/check-spelling/check-spelling/wiki/Feature:-Area-dictionaries 4. a base rule for determining what _might_ be words -- currently that's roughly `[a-zA-Z']{3,x}` -- see https://github.com/check-spelling/check-spelling/wiki/Feature:-Autodetect-valid-word-lengths (fwiw, I'm working on relaxing this rule, and hope to be able to support non-English languages at least by the end of 2022, but hopefully considerably sooner) 5. a way to recognize jumbled words -- currently, that's roughly https://github.com/check-spelling/check-spelling/blob/prerelease/lib/CheckSpelling/UnknownWordSplitter.pm#L139-L156 (I've only recently started refactoring this, and eventually would hope to have been able to point to test coverage, but, for now, code is king, but the general goal is https://www.check-spelling.dev/#programmer-friendly). The reporting (squiggles) is left entirely as a problem for the implementer.
claunia commented 2026-01-31 04:39:44 +00:00
Author
Owner
Copy Link

@WSLUser commented on GitHub (Oct 8, 2021):

I just did also have idea of wondering if there's perhaps a VT sequence that could also address this. A terminal application would need to opt in of course but then git, vim, etc. could enable spell-checking and do whatever it wants as far as UI goes (or leave it entirely to the terminal). I could see this as being a particularly useful sequence.

@j4james Do you know if such a sequence exists or has been brought up before for inclusion by the major terminals? Could WT do their own thing if needed if this is the route we'd want to take?

@WSLUser commented on GitHub (Oct 8, 2021): I just did also have idea of wondering if there's perhaps a VT sequence that could also address this. A terminal application would need to opt in of course but then git, vim, etc. could enable spell-checking and do whatever it wants as far as UI goes (or leave it entirely to the terminal). I could see this as being a particularly useful sequence. @j4james Do you know if such a sequence exists or has been brought up before for inclusion by the major terminals? Could WT do their own thing if needed if this is the route we'd want to take?
claunia commented 2026-01-31 04:39:44 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Oct 8, 2021):

I think in most cases this sort of thing would be best handled by the applications themselves. For example if you're in and editor, and you're viewing a document with horizontal scrolling, you're going to have words at either margin that are potentially truncated. The editor itself will know what the full word is, and can tell whether it's correctly spelled or not, but the terminal can't. Same sort of thing can happen in the command line when you've got text wrapping from one line to the next.

But if there's really a big demand for something like this, maybe it could be implemented as an extension on top of the proposed framework for pattern recognizers (#6969).

@j4james commented on GitHub (Oct 8, 2021): I think in most cases this sort of thing would be best handled by the applications themselves. For example if you're in and editor, and you're viewing a document with horizontal scrolling, you're going to have words at either margin that are potentially truncated. The editor itself will know what the full word is, and can tell whether it's correctly spelled or not, but the terminal can't. Same sort of thing can happen in the command line when you've got text wrapping from one line to the next. But if there's really a big demand for something like this, maybe it could be implemented as an extension on top of the proposed framework for pattern recognizers (#6969).
claunia commented 2026-01-31 04:39:44 +00:00
Author
Owner
Copy Link

@WSLUser commented on GitHub (Oct 12, 2021):

That sounds like the perfect solution for this.

@WSLUser commented on GitHub (Oct 12, 2021): That sounds like the perfect solution for this.
claunia commented 2026-01-31 04:39:44 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Oct 14, 2021):

You know, I'm gonna agree that this is something the CLI application should handle themselves. Think of something like tmux, where you've potentially got words that are wrapped in the middle of the buffer onto the next line:

this is a longe|This is a totally differe
r sentence whic|nt pane that's wrapped at
h is split in t| the right edge
he middle of th|
e buffer       |

Trying to spellcheck that on the terminal side would be a nightmare. A good suggestion for vim or emacs maybe!

@zadjii-msft commented on GitHub (Oct 14, 2021): You know, I'm gonna agree that this is something the CLI application should handle themselves. Think of something like tmux, where you've potentially got words that are wrapped in the middle of the buffer onto the next line: ``` this is a longe|This is a totally differe r sentence whic|nt pane that's wrapped at h is split in t| the right edge he middle of th| e buffer | ``` Trying to spellcheck that on the terminal side would be a nightmare. A good suggestion for vim or emacs maybe!
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 Issue-Feature Needs-Tag-Fix Needs-Triage Resolution-Won't-Fix
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#15477
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?