[PSS 2016] The headaches of Primal Sense's Autocomplete

Post feature requests, product enhancement ideas, and other product-specific suggestions here. Do not post bug reports.
Forum rules
Do not post any licensing information in this forum.
This topic is 7 years and 8 months old and has exceeded the time allowed for comments. Please begin a new topic or use the search feature to find a similar but newer topic.
Locked
Bosparan
Posts: 290
Last visit: Fri Oct 08, 2021 11:59 am

[PSS 2016] The headaches of Primal Sense's Autocomplete

Post by Bosparan »

Hi Guys,

I've come to vent a bit on an old issue that really hurts the comfort of using PowerShell Studio for us:

Primal Sense's handling of autocomplete
Basically, the autocomplete functionality is driving me nuts, but it's too useful to go completely without.
Major points of irritation:
- Autocomplete turns powershell statements into cmdlets/functions
- Autocomplete turns accelerated types into cmdlets/functions

Typically recommended mitigation:
Configure autocomplete on exact match only. Which is about as good as killing autocomplete entirely and deprives us of all its benefits.

Usually used mitigation:
- Switch to PowerShell version 2 mode to reduce number of incidents.
- Curse frequently to vent steam

Everyday occurrences of issue:
- Every bloody time one wants to create a foreach ($a in $b) loop, it will turn foreach into foreach-object.
- Every bloody time one wants to create a [switch] typed parameter, it will turn it into the Switch-Certificate cmdlet (PKI Module)
- Every time one types "Begin" (for an advanced function), you end up with a WebAdministration cmdlet
- Most times we type "Process", we end up with Process-Data, one of our standard names for nested, non-published functions

Requested solution:
For autocomplete (but not Primal Sense) on functions, only start after there is a "-" in the string.
Example consequences:
- Autocomplete for Foreach-Object would then start at "ForEach-"
- Autocomplete for Switch-Certificate would then start at "Switch-"
This would - with a single change - permanently eliminate the problem with all PowerShell statements (which intentionally don't use "-" characters) and any type accelerator that is added by default for versions 2 through 5 so far.

So please, please, please do something about this. Not necessarily my solution (though I think it's an elegant way to do this), but this has been driving me borderline crazy for at least a year now.

Cheers and thanks for taking the time,
Bosparan

PS: Here's the previous request on the topic:
viewtopic.php?f=9&t=9056
User avatar
davidc
Posts: 5913
Last visit: Mon Jul 08, 2019 8:55 am
Been upvoted: 2 times

Re: [PSS 2016] The headaches of Primal Sense's Autocomplete

Post by davidc »

Have you tried disabling the "Enable word completion while typing" feature in Options->PrimalSense?

By disabling this feature, you will prevent the PrimalSense displaying middle of typing unless you press a trigger such as a dash or period, thus preventing keyword overriding.
And if you want to the force the PrimalSense to display, simply press [Ctrl + Space].
David
SAPIEN Technologies, Inc.
Bosparan
Posts: 290
Last visit: Fri Oct 08, 2021 11:59 am

Re: [PSS 2016] The headaches of Primal Sense's Autocomplete

Post by Bosparan »

Hi David,

yes, I had tried that ... quite some time ago. Back then it was just not usable (as bad as turning Primal Sense off entirely). The current version should be a workable workaround. Note that it currently can't handle it when you go back and change the verb after starting to type (So if I type "Switch-" it will provide Primal Sense for Switch-Certificate. Going back and changing it to "New-" will not cause it to repopulate the list until cancelled). That's not too much of an issue though, thanks a lot for the advice David :)

Still, I think that the current behavior of auto-complete is fundamentally flawed: It's counter intuitive to provide autocomplete for some cmdlet/function when the input also matches an everyday use statement/accelerator.
Adding those statements and accelerators to Primal Sense with a higher selection priority would probably work well, and it allows leaving the current primal sense / autocomplete mechanics untouched.

Cheers,
Bosparan
User avatar
davidc
Posts: 5913
Last visit: Mon Jul 08, 2019 8:55 am
Been upvoted: 2 times

Re: [PSS 2016] The headaches of Primal Sense's Autocomplete

Post by davidc »

FYI, we just fixed the behavior of the dash PrimalSense. It will now close when you backspace back to the dash and it update the list if the verb was changed.
We also updated the casting PrimalSense so that it shows Types and Namespaces only.

As for the keyword issue, there are workarounds and I will bring it up with the team. The problem is a solution for one person is a problem for another. Meaning people have very different preferences and sometimes and we have to try to find a happy medium.

Personally, I have "Autocomplete on exact match only" enabled and I press TAB instead of Space when I want the PrimalSense to autocomplete the highlighted item, thus I never have to deal with the keyword replacement issue. All it takes is switching a key press and I still get the complete benefits of PrimalSense.
David
SAPIEN Technologies, Inc.
Bosparan
Posts: 290
Last visit: Fri Oct 08, 2021 11:59 am

Re: [PSS 2016] The headaches of Primal Sense's Autocomplete

Post by Bosparan »

Hi David,
davidc wrote:FYI, we just fixed the behavior of the dash PrimalSense. It will now close when you backspace back to the dash and it update the list if the verb was changed.
Nice :)
I noticed those issues, but wasn't too bothered by that (developers usually develop a healthy resistance to typos. I at least have, so I rarely have to go back and fix something ... unless autocomplete messes with me, which thanks to your advice it no longer does).
davidc wrote:We also updated the casting PrimalSense so that it shows Types and Namespaces only.
Does it recognize type accelerators as well? Otherwise, setting up [switch]-Parameters might be un-fun. While I'm at it, I'd love to be able to configure my own type accelerators for a project, which are thereafter recognized by Primal Sense :)
davidc wrote:The problem is a solution for one person is a problem for another.
Oh don't I know it *sigh*
I know, I don't need to tell you guys about contradictory requests ... suffice to say I get my own share of it.
You've already done a marvelous job of implementing a lot of it via options that give users a choice.
davidc wrote:Personally, I have "Autocomplete on exact match only" enabled and I press TAB instead of Space when I want the PrimalSense to autocomplete the highlighted item, thus I never have to deal with the keyword replacement issue. All it takes is switching a key press and I still get the complete benefits of PrimalSense.
And yet another thing I learn. Never noticed I could just tab it into existence. I'm certainly staying with my current configuration though - space and dot are better located for my typing flow than tab ... and I need to type them anyway, when using tab to complete it.
I frequently use tab to expand aliases though ("%" + "Tab" is just faster than "Foreach-Object"-ing it).

Cheers,
Bosparan
User avatar
davidc
Posts: 5913
Last visit: Mon Jul 08, 2019 8:55 am
Been upvoted: 2 times

Re: [PSS 2016] The headaches of Primal Sense's Autocomplete

Post by davidc »

You can declare additional accelerators (global scale) by creating the following text file:

C:\ProgramData\SAPIEN\PowerShell Studio 2016\Accelerators.cache

Declare each accelerator on its own line and use the following format:
  1. shortcutname|Full Type name
Example:
  1. wmiclass|System.Management.ManagementClass
Note: This does not define the accelerator in PowerShell. This file is only used for syntax coloring and PrimalSense.
David
SAPIEN Technologies, Inc.
Bosparan
Posts: 290
Last visit: Fri Oct 08, 2021 11:59 am

Re: [PSS 2016] The headaches of Primal Sense's Autocomplete

Post by Bosparan »

Hi David,

thanks for yet another helpful tip. Worked like a charm.
It may be good to allow configuring this on a per-project basis, but Global is already quite helpful, at least for our primary library (which is already rather ... well-used).
Actually ... with the global option available, it might not be worth implementing this on a per-project basis. We'll use it, for sure, but in general I don't see this getting enough use to justify the effort of implementing this.

Cheers and thanks again,
Bosparan
This topic is 7 years and 8 months old and has exceeded the time allowed for comments. Please begin a new topic or use the search feature to find a similar but newer topic.
Locked