Skip to content

Stop replacing variables in path tab completion#21148

Open
MartinGC94 wants to merge 2 commits intoPowerShell:masterfrom
MartinGC94:DontReplaceVarsInPathCompletion
Open

Stop replacing variables in path tab completion#21148
MartinGC94 wants to merge 2 commits intoPowerShell:masterfrom
MartinGC94:DontReplaceVarsInPathCompletion

Conversation

@MartinGC94
Copy link
Copy Markdown
Contributor

@MartinGC94 MartinGC94 commented Jan 28, 2024

PR Summary

Improves tab completion so variables don't get replaced when tab completing paths, for example: ls $env:windir\System3<Tab> will tab complete to: ls $env:windir\System32 instead of ls C:\Windows\System32.
The way it works is that the variables are resolved, and the resulting string is used to find valid path completions, then the variable text is inserted back into the discovered paths. Because of this implementation it's not perfect, you can trick it to insert the variable into the wrong place, for example:

$Var = "C"
ls C:\Windows\System32\${Var}onfi<Tab>

turns into ${Var}:\Windows\System32\config\ instead of the expected: C:\Windows\System32\${Var}onfig\
in practice it shouldn't be an issue because people usually use variables to define the root of a path, or to define entire path segments with more unique names.

PR Context

Fixes #5350

PR Checklist

@pull-request-quantifier-deprecated
Copy link
Copy Markdown

This PR has 406 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!


Quantification details

Label      : Extra Large
Size       : +246 -160
Percentile : 80.2%

Total files changed: 3

Change summary by file extension:
.cs : +227 -147
.ps1 : +19 -13

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

  • Fast and predictable releases to production:
    • Optimal size changes are more likely to be reviewed faster with fewer
      iterations.
    • Similarity in low PR complexity drives similar review times.
  • Review quality is likely higher as complexity is lower:
    • Bugs are more likely to be detected.
    • Code inconsistencies are more likely to be detected.
  • Knowledge sharing is improved within the participants:
    • Small portions can be assimilated better.
  • Better engineering practices are exercised:
    • Solving big problems by dividing them in well contained, smaller problems.
    • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

  • Use the PullRequestQuantifier to quantify your PR accurately
    • Create a context profile for your repo using the context generator
    • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
    • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
    • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
  • Change your engineering behaviors
    • For PRs that fall outside of the desired spectrum, review the details and check if:
      • Your PR could be split in smaller, self-contained PRs instead
      • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

  • One line was added: +1 -0
  • One line was deleted: +0 -1
  • One line was modified: +1 -1 (git diff doesn't know about modified, it will
    interpret that line like one addition plus one deletion)
  • Change percentiles: Change characteristics (addition, deletion, modification)
    of this PR in relation to all other PRs within the repository.


Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

@MartinGC94 MartinGC94 changed the title Stop replacing vars in path tab completion Stop replacing variables in path tab completion Jan 28, 2024
@microsoft-github-policy-service microsoft-github-policy-service bot added the Review - Needed The PR is being reviewed label Feb 5, 2024
@SeeminglyScience SeeminglyScience added WG-Interactive-Console the console experience WG-NeedsReview Needs a review by the labeled Working Group labels Dec 4, 2024
@theJasonHelmick theJasonHelmick added WG-Reviewed A Working Group has reviewed this and made a recommendation and removed WG-NeedsReview Needs a review by the labeled Working Group labels Dec 4, 2024
@SeeminglyScience SeeminglyScience removed the WG-Reviewed A Working Group has reviewed this and made a recommendation label Dec 4, 2024
@SeeminglyScience
Copy link
Copy Markdown
Contributor

The Interactive WG discussed this. We love the change (and I desperately want it) but we think we need to have a larger conversation about configuring completion preferences before we could take this change (and changes like stopping ~ expansion).

I can't give any sort of timeline on when those conversations will complete (nor when the result of them will be implemented). It's up to you if you'd like to keep this PR open until that time comes or open a new one at that time.

@MartinGC94
Copy link
Copy Markdown
Contributor Author

we think we need to have a larger conversation about configuring completion preferences before we could take this change

Relevant issue: #18963 and PR: #19518

@iSazonov iSazonov added the Blocked blocked on something external to this repo label Jan 2, 2025
@froh
Copy link
Copy Markdown

froh commented Feb 17, 2026

we think we need to have a larger conversation about configuring completion preferences

a year has passed... I boldly dare to ask how are things are going with these conversations :-) ?

@sdwheeler
Copy link
Copy Markdown
Collaborator

After further discussion in the Working Group, our conclusion is that the user experience introduces too many non-optimal or unsupportable scenarios.

@sdwheeler sdwheeler added WG-Reviewed A Working Group has reviewed this and made a recommendation Resolution-Declined The proposed feature is declined. and removed Review - Needed The PR is being reviewed labels Apr 1, 2026
@MartinGC94
Copy link
Copy Markdown
Contributor Author

It would be nice if some examples of these non-optimal scenarios could be posted. I mean I recognize that it's not perfect, but like I said in the OP, I think the scenarios where it helps are way more common than the scenarios where it doesn't work. And besides, there's nothing stopping us from making it an opt-in feature.

In my eyes there is no way to build a perfect solution for string + variable completion. I can only think of 3 approaches:

1: The current one where variables are simply discarded.
2: String completion is greatly simplified so it it's only possible to trigger completions for the last path segment, and everything before the last path segment is left as it was.
3: The replacement logic that I tried to implement here (though perhaps some better logic can be devised).

So we have to be pragmatic here. Is 1 really the best overall approach? I don't think so. 2 would be the easiest way to implement a bug-free version for, but it would obviously come at the cost of current features like automatically adding quotes and expanding wildcards.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Blocked blocked on something external to this repo Extra Large Resolution-Declined The proposed feature is declined. WG-Interactive-Console the console experience WG-Reviewed A Working Group has reviewed this and made a recommendation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Tab completion should not replace ~ or variables

6 participants