Please make backward and forward search slash agnostic, or add an option to do so
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
Research direction
Start by tracing the Ctrl+R history-search entry point described in the issue and how the query is compared with stored commands. Reproduce the Windows slash-mismatch scenario, then define whether matching is always slash-agnostic or controlled by an option. Done means a forward-slash query finds the recorded backslash command, with coverage for the selected behavior.
Written by the indexing model from the issue text.
Description
Description of the new feature/enhancement
As a PSReadline user,
When I press Ctrl+R and start typing a command that includes a path,
I would like to be able to type either slash (backward or forward) and have it match whatever slash is in PSReadline history.
Justification
I have become accustomed to typing in forward slashes in PowerShell, because they work regardless of the environment I am in. I also use tab completion. Tab completion in PowerShell on Windows changes forward slashes to backward slashes. This is fine, but it makes it difficult to work with command history because later on, when I want to repeat a command with the same path, and I press Ctrl+R and then start typing the path with forward slashes, on Windows it doesn't match what I ran before because what I ran before was converted to using backward slashes. If instead PSReadline had an option (or worked by default) to match forward slashes with backward slashes in command history, this wouldn't be a problem, and I could access historic commands on Windows using the forward slash that I naturally type with.
Steps to reproduce the issue that this would resolve
- Run a command that includes a path with slashes. For example:
& ./MySolutionFolder/MySolution.sln. Use tab completion as you type that command in on Windows so that the command that actually gets run is& .\MySolutionFolder\MySolution.sln. - Press Ctrl+R.
- Type in
& ./MySolutand notice how it does not present your historic& .\MySolutionFolder\MySolution.slncommand from history. Although this command was typed in using forward slashes, what was run and recorded was a command using backward slashes on Windows, so it doesn't match.
- Dominant language
- C#
- Stars
- 4.4k
- Forks
- 341
- PR merge metrics
- No merged PRs in 30d
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from PowerShell/PSReadLine
-
Needs-Triage :mag:
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
PowerShell/PSReadLine#5205 ·
-
Needs-Triage :mag:
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
PowerShell/PSReadLine#5195 ·
-
Needs-Triage :mag:
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
PowerShell/PSReadLine#5121 ·
-
Needs-Triage :mag:
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
PowerShell/PSReadLine#5045 ·
-
Area-CommandHelp Issue-Enhancement
Difficulty 1/5 Under an hour Newbie friendliness 68/100
PowerShell/PSReadLine#3470 · 3 reactions ·
All issues in PowerShell/PSReadLine
Similar issues
-
bug
Difficulty 1/5 Under an hour Newbie friendliness 75/100
sillsdev/languageforge-lexbox#2665 ·
-
bug documentation frontend
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
azurenoops/spin_agent#975 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
-
:watch: Not Triaged 11.0 fundamentals/subsvc
Difficulty 2/5 1-3 hours Newbie friendliness 92/100
dotnet/AspNetCore.Docs#37699 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
SubtitleEdit/subtitleedit#15108 · 1 comment ·