Alignment issues in some hosts with Format-Wide (May be Nerd Fonts V3 specific)

[JK-Flip-Flop96]

Expected Behavior

Get-ChildItem | Format-Wide should produce output in aligned columns

Current Behavior

"ls" in the above screenshot is aliased to a function that ultimately outputs Get-ChildItem | Format-Wide -AutoSize with some arguments passed to GCI. I've tested with the exact command too. ]

Doesn't affect long listing (plain Get-Childitem) or a custom Tree-like function (that invokes Format-TerminalIcon) which I wrote for my profile.

(Ignore my attempts at obscuring my employer in the above, realised it was futile when it's literally in my profile bio 😆)

Possible Solution

I suspect this is something to do with the rendering of wide glyphs by the terminal. But I've been unable to narrow it down to a specific subset of glyphs.

Steps to Reproduce (for bugs)

1. Install a build of the NF v3 compatible HEAD
2. Open Powershell in one of the hosts mentioned below
3. Import the built Module
4. gci | fw

Context

Tested Environments

Windows Terminal.

It appears to work in 1.16 but doesn't work in 1.17 and 1.18 Preview (Shown above).

conhost.exe (pwsh.exe)

Closer to working correctly, some entries appear with a 3 wide gap between the icon and the name.

Alacritty

Works as intended

Other observations

Outputs are consistent, you always get the same icons offset by the same amount given, provided the setup is the same (host/font/font size/number of columns/screen width).

I also tested in Hyper.js with an NF v2 font with an NF v3 theme still set and the results were similar to WT. (Couldn't be bothered to update the font on a terminal app I don't use)

Your Environment

• Module version used: I am working on a PR for Default color for Files/Dirs #102 so my build isn't a clean build of the NF v3 HEAD. I don't believe that I was experiencing this in 0.10.0. I believe that there should be no relation between this issue and my changes. My forked repo contains all of the changes if you want to review them to be certain.
• Operating System and PowerShell version: Win 10 21H2, PS 7.3.4/PS 7.4.0-Preview
• Theme is a conversion of the stock theme with all of the colours set to the nearest colour from the Catppuccin palette using a Python script I wrote. I have tested with stock too though.

Apologies for having so many variables in my testing, I just tried everything I had on hand out of interest 😅.

Please let me know if this issue should be passed on to the Microsoft/terminal repo or elsewhere.

[MattKotsenas]

I only just started to look into this, but I'd assume this is because of surrogate pairs (I'm not great at fonts, so I might be getting terms wrong).

It appears that if an icon uses the material design font section, its represented as two UTF-16 code points. That's then causing a miscalculation of string length.

Here's a snippet of a potential workaround:

diff --git a/Terminal-Icons/Private/Resolve-Icon.ps1 b/Terminal-Icons/Private/Resolve-Icon.ps1
index 3c2c071..58e0e40 100644
--- a/Terminal-Icons/Private/Resolve-Icon.ps1
+++ b/Terminal-Icons/Private/Resolve-Icon.ps1
@@ -127,6 +127,11 @@ function Resolve-Icon {
             $displayInfo['Icon'] = $null
         }
         $displayInfo['Color'] = $colorSeq
+
+        #$Host.UI.WriteLine("Before: $($displayInfo['Icon']) $($displayInfo['Icon'].Length)")
+        if ($displayInfo['Icon'].Length -eq 1) { $displayInfo['Icon'] = ([char]0x00).ToString() + $displayInfo['Icon']  }
+        #$Host.UI.WriteLine(" After: $($displayInfo['Icon']) $($displayInfo['Icon'].Length)")
+
         $displayInfo
     }
 }

Here at the end of Resolve-Icon, I check to see if the icon is a single code point. If so, I pad it with a NUL character. I wouldn't recommend this as the actual solution, just a proof-of-concept.

[MattKotsenas]

I filed PowerShell/PowerShell#23861 as I think this is also an upstream issue in PowerShell.

That said we probably should work around the issue here as well, given that this is unlikely to be a quick fix.

[MattKotsenas]

This feels like something that could be fixed easily without performance impact after #120 is in, as the list could be processed at build time and add the appropriate padding.

@devblackops I'm happy to do the work here, but the approach will depend on the outcome of 120. Let me know how best to proceed.