EliziumNet / Loopz

PowerShell iteration utilities with additional tools like the Parameter Set Tools
https://eliziumnet.github.io/Loopz/
MIT License
3 stars 0 forks source link

Signals: need a way to determine if the host is capable of displaying emojis #115

Open plastikfan opened 3 years ago

plastikfan commented 3 years ago

The standard console on windows does not render emojis and the same probably applies to PowerShell ISE. We need to detect if the host can render emojis. We need to define an alternate scheme which uses ascii characeters instead of unicode characters.

The following needs to be implemented

plastikfan commented 3 years ago

See this Why should cmdlets not use the Console API?

and this PSHost Class

plastikfan commented 3 years ago

It looks as though this is not easily solvable at the moment. As a result of raising this issue ( How to determine if the current host can display emoji characters programmically ), the best solution for now is to perform multiple application specific checks and invoke via invoke-ByPlatform.

For windows:

the rest tbd

plastikfan commented 3 years ago

A note about codepoints: What's the difference between a character, a code point, a glyph and a grapheme?

plastikfan commented 3 years ago

Changing Krayola's use of pair is way too destructive. Another aolution will be required instead. We need to maintain the pair structure and can do so by creating a new function that takes the original pair and a non unicode chacter sequence and create the actual pair depending on what info has been gleened from the execution environment. initialize-Signals assumes the signals are defined as pairs. So we can change this so that it only expects an array, which will now be a 3 element array, with the 3rd element being the non unicode defintion.

plastikfan commented 3 years ago

NB: it was initially thought that I would have to modify Update-CustomSignals to provide a non unicode representation of the custom override signal. However, it soon transpired that this was not necessary. An example usage of the override definied in the user profile would look something like this:

[hashtable]$MySignals = @{
  'PATTERN' = $(kp(@('Pattern', '🎃')));
  'WHAT-IF' = $(kp(@('What If', '💜')));
}
Update-CustomSignals -Signals $MySignals;

Note, the creation of a pair instance via kp. Since Update-CustomSignals is working in the 'pair', realm as opposed to the 'array' realm, no change is required. Initialize-Signals, now take a hash of 3 item arrays (the array realm) and coverts that to a hash of pairs (the pairs realm).

plastikfan commented 3 years ago

NB: this representation (About Special Characters):

"`u{1F4A9}"

of a unicode character is only supported on Powershell version 7.0+

plastikfan commented 3 years ago

Argh, just discovered that Show-AsTable is at fault. It is still using ApiFormat on Krayon when it should be migrated to use the Scribbler.

Actually, this isnt as bad as initially thought. ApiFormatWithArg and ApiFormat are still defined on the Krayon, but its better to use the Snippets function on the Scribbler (which refers to ApiFormatWithArg and ApiFormat anyway).

plastikfan commented 3 years ago

I have refrained from completing this:

for the time being because that representation is only supported on powershell 7.1, but more importantly, if this change were made, the source fle (globals.ps1) would become human unreadable. There is a balancing act here, because I'm not sure if its ok to have a source code file as UTF-8 with BOM (as it currently is, with the embedded emojis which clearly aids human readability). Not quite a hobson's choice, but there is a problem.

See: about_Character_Encoding