Path info in default z output is clipped

[rkeithhill]

The clipping below is unfortunate:

z

Name                           Value
----                           -----
C:\Users\Keith                 49
C:\Users\Keith\GitHub          2
C:\Users\Keith\GitHub\dahlb... 6
C:\Windows\System32            13
C:\Users\Keith\Code\electro... 16
C:\Users\Keith\Code\electro... 26

Maybe you could just switch the default order Name and Value e.g.:

z | ft Value,Name

Value Name
----- ----
   52 C:\Users\Keith
    2 C:\Users\Keith\GitHub
    6 C:\Users\Keith\GitHub\dahlbyk\posh-git
   13 C:\Windows\System32
   16 C:\Users\Keith\Code\electron-app\dist
   26 C:\Users\Keith\Code\electron-app

[vors]

Totally! Would you like to send a PR? :)

[rkeithhill]

I'll take a look at it tonight.

[cspotcode]

I think you'll have to set a defaultdisplaypropertyset on the returned values.

https://docs.microsoft.com/en-us/dotnet/api/system.management.automation.runspaces.typedata.defaultdisplaypropertyset?view=powershellsdk-1.1.0

It might be tricky because it's technically a single Hashtable value being returned, which I think is being enumerated as a bunch of DictionaryEntrys. So they're controlling the rendering. You might need to replace the returned value with some sort of custom collection.

[rkeithhill]

Yup, I was initially trying to stick with the hashtable and give the "DictionaryEntry" objects a new type name in their typenames collection. But GetEnumerator() generates new DictionaryEntry objects. :-(

[cspotcode]

We can create a custom entry type with Weight and Path fields. Those are better names for the output anyway. I normally do that with classes but some people try to avoid class syntax, so I guess it depends on what we want to use / avoid here.

…

On Wed, Sep 19, 2018, 7:19 PM Keith Hill ***@***.***> wrote: Yup, I was initially trying to stick with the hashtable and give the "DictionaryEntry" objects a new type name in their typenames collection. But GetEnumerator() generates new DictionaryEntry objects. :-( — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#60 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAW-uC63JMNi5t8MIbY5QAkY7JvKuXu-ks5uctEDgaJpZM4Wkisp> .

[rkeithhill]

Class syntax would limit this module to v5 and higher. I don't think that is ideal but it's up to @vors. Maybe we could return a PSCustomObject but maintain a module level, private variable that is the hashtable for quick lookup of the weight from the path (key). Also, to work better on Linux the hashtable/dictionary should be case-sensitive.

[cspotcode]

Case sensitivity is implemented in my PR fixing #61: #62

…

On Wed, Sep 19, 2018, 9:05 PM Keith Hill ***@***.***> wrote: Class syntax would limit this module to v5 and higher. I don't think that is ideal but it's up to @vors <https://github.com/vors>. Maybe we could return a PSCustomObject but maintain a module level, private variable that is the hashtable for quick lookup of the weight from the path (key). Also, to work better on Linux the hashtable/dictionary should be case-sensitive. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#60 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAW-uPCnFQpcV6ta6IBU47Kqv0BJFrzgks5ucunJgaJpZM4Wkisp> .

[vors]

I opened #64 for the 5.0 question, I'm a little bit on the fence about it.
I think this works ( 🤷‍♀️ ):

... .GetEnumerator() | Select-Object -Property Name, Value

[rkeithhill]

If we only intend to change the behavior of Invoke-Location (and z - alias to this function) that should work. Although it would need to be something like this:

    if ($null -eq $match) {
        Get-ZLocation |
            ForEach-Object GetEnumerator |
            Select-Object @{Name='Weight';Expression={$_.Value}},@{Name='Path';Expression={$_.Name}}
        return
    }

Outputs:

Weight Path
------ ----
     3 C:\Users\Keith\GitHub\rkeithhill\ZLocation
     1 C:\Users\Keith
     6 C:\Users\Keith\GitHub\rkeithhill\ZLocation\ZLocation

Although that outputs a series of DictionaryEntry objects with Weight/Path properties tacked on. That feels a bit odd. The output of Invoke-Location is not internally used so we could probably get away with changing the output from hashtable to something else. I think a set of PSCustomObjects would probably be better. External users can still access the hashtable by calling Get-ZLocation. Thoughts? If you agree in principle I submit a PR for this.

[rkeithhill]

OK, this is the [PSCustomObject] version:

    if ($null -eq $match) {
        Get-ZLocation |
            ForEach-Object {$_.GetEnumerator()} |
            ForEach-Object {[PSCustomObject]@{Weight = $_.Value; Path = $_.Name}}
        return
    }

Now, need to figure out how far back [PSCustomObject] goes. I think it goes back to v3. If so, we'd be good.