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

[plastikfan]

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

• Define mutiple functions on a per platfrom level to determine if emojis can be displayed
• The data structure holding signals will contain an extra field contain non emoji representation of the signal
• Change Show-Signals to use the new table functionality to display the signals in a coloured table (this will act as a show-case for the table functionality)

[plastikfan]

See this Why should cmdlets not use the Console API?

and this PSHost Class

[plastikfan]

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:

• Windows Terminal: check if $env:WT_SESSION is set
• Fluent terminal: $env:TERM_PROGRAM => FluentTerminal
  (PS: $env:TERM_PROGRAM not supported by WC or WT)

the rest tbd

• Feature Request: Clients of terminal need a way to inquire about the capabilities of the terminal microsoft/terminal#1040
• https://docs.microsoft.com/en-us/dotnet/standard/base-types/character-encoding
• https://docs.microsoft.com/en-us/dotnet/api/system.text?view=net-5.0

[plastikfan]

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

[plastikfan]

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]

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]

NB: this representation (About Special Characters):

"`u{1F4A9}"

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

[plastikfan]

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]

I have refrained from completing this:

• Use unicode string to represent emojis, eg "`u{1F4A9}"

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