Terminal: Emoji-Unterstützung zur Windows-Konsole hinzufügen

Schon im Rückstand :)

Süss! Ein weiterer Anwendungsfall: Ich habe eine Kommandozeilen-App, die Warnungen mit ⚠ ausgibt.

@zadjii-msft wird dies Unterstützung für nicht-lateinische Unicode-Zeichen beinhalten? dh können arabische oder japanische Zeichen, die in der aktuell bereitgestellten Konsolenschriftart nicht gefunden werden, mit einer anderen Schriftart angezeigt werden?

Hypothetisch ja.

Arabisch ist jedoch irgendwie ein eigenes Problem - es gibt so gut wie keine Chance, dass wir in absehbarer Zeit eine Sprachunterstützung von links nach rechts implementieren werden, aber die Zeichen könnten möglicherweise korrekt gerendert werden.

@adiviness kann mehr zu dem Thema

Arabisch ist aufgrund der zusätzlichen Unterstützung, die für bidirektionalen Text und Ligaturen erforderlich ist, schwierig. Soweit mir bekannt ist, wird dies derzeit nicht von vielen Terminalemulatoren unterstützt.

Es gibt auch einen Unterschied zwischen der Konsole, die Emojis rendern kann und der Unterstützung von Font-Fallback, wenn die aktuelle Schriftart keine Glyphe hat. Beides sind Punkte in unserem Backlog.

+1 Unsere Build- und CI-Skripte haben Emojis für den Erfolg ✔️, Warnungen ⚠ und Fehler ❌ zum schnellen, produktiven Betrachten von Protokollen.

Können wir bei Problemen bitte nicht +1 geben? Bitte nutzen Sie Reaktionen oder abonnieren Sie Benachrichtigungen.

@miniksa , ich würde mich nicht zu sehr von +1 ablenken lassen. Du könntest es komplett ignorieren. Der Hauptzweck des Tippens bestand darin, den Anwendungsfall zu artikulieren. Vermutlich dürften Plattform-/Produktbesitzer sehr an Anwendungsfällen von Kunden interessiert sein ... gedacht, in diesem Fall ist es nicht zu extravagant.

@SidShetye - schätzen Sie Ihren Kommentar - Ihr Anwendungsfall ist nicht ungewöhnlich, aber es ist nützlich, davon zu hören.

Im Allgemeinen bitten wir die Leute, nicht +1 zu geben, weil wir vermeiden möchten, dass Personen (insbesondere ohne weiteren Kommentar) +1 geben, was nur als Rauschen endet und das Parsen und Verwalten von Threads erschwert.

Das Teilen zusätzlicher Kommentare, Kontext, Beobachtungen, Probleme usw. ist WEIT wertvoller als ein +1 ;)

Seltsam, dass es niemand erwähnt hat, aber der Yarn-Paketmanager verwendet Emojis und es ist etwas nervig, dass sie nur als Quadrate angezeigt werden :/

Danke @destruktiv-dragon - es gibt viele Tools, die Emojis enthalten/emittieren, aber die Konsole kann sie noch nicht rendern.

@bitcrazed Du hast in diesem Twitter-Thread zum Conpty-Release erwähnt, dass wir noch auf einen neuen Puffer und einen neuen Renderer (DirectWrite) warten müssen. Sind das die einzigen beiden großen Blocker, die noch übrig sind?

@kavdev Im Wesentlichen ja. Um Emoji-Glyphen anzuzeigen, müssen wir zunächst (möglicherweise zusammengesetzte) Unicode-Codepunkte für jede Glyphe speichern (zB Ninjacats), aber wir müssen sie auch rendern können, was einen Font-Fallback erfordert, was GDI nicht tut t unterstützen.

Wir werden an Verbesserungen sowohl der Textpufferimplementierung der Konsole als auch des Renderers in zukünftigen Versionen arbeiten.

@bitcrazed
Viele Emoji sind zusammengesetzt, dh sie haben mehrere Codepunkte, die miteinander verbunden sind (mit ZWJ oder VS oder was auch immer), und in den meisten Fällen passen sie nicht in eine Konsolenzelle. Ihr Problem ist also nicht "1 Zelle bis n Zeichen", sondern "m Zellen bis n Zeichen" ...

FWIW, mein Terminalemulator und iTerm2 rendern beide Emoji, indem sie im Grunde genommen als Zeichen im CJK-Stil mit "voller Breite" (2 Zellen) behandelt werden. Ich weiß nichts über iTerm2, aber ich unternehme keinen Versuch, Unicode-"Modifikatoren" für Emoji oder andere Zeichen zu unterstützen. Jedes Zeichen muss ein Unicode-Codepunkt sein, obwohl es normale Breite oder volle Breite haben kann.

@sedwards2009
Die ultimative Lösung sollte eine Unicode- oder eine andere Spezifikation sein, die uns sagt, wie man komplexe Skripte in einem Zeichenraster handhabt.

Die naheliegendste Idee könnte sein, einige Konzepte aus der Ausrichtung anzuwenden (wie das Einfügen von Leerzeichen zwischen ostasiatischen Zeichen und das Einfügen von Kashida, wenn arabische Zeichen in das Raster eingefügt werden), aber die Umsetzung der Ausrichtung ist ein totales Durcheinander. AFAIK DWRITE leistet bisher den besten Job, aber einige Implementierungen (wie Kashida) sind immer noch sehr hackig.

Nur ein Kommentar, der nützlich sein könnte - bestimmte Emoji- und Unicode-Symbole funktionierten früher , ich würde einige auf meinem WSL-Login-Banner anzeigen, z. Hyper, VS-Code)
Einige Symbole funktionieren jedoch im Jahr 1809, wie z. B. ☕ (U+2615), aber ich denke, sie befinden sich in anderen Teilen des Unicode-Spektrums, dh in viel niedrigeren Codepunkten

Das Oktober-Update scheint in dieser Hinsicht eher einen Rückschritt als einen Fortschritt zu bringen. Ich konnte zuvor alle Unicode-Symbole verwenden, die ich im VS Code-integrierten Terminal getestet habe (das Powershell verwendet), aber nach dem Oktober-Update werden alle Emojis und bestimmte fremdsprachige Zeichen nicht richtig gerendert.

Dies scheint tatsächlich ein halbsystemweites Schriftproblem zu sein, da selbst Konsolenemulatoren wie ConEmu Emoji jetzt nicht richtig rendern.

@Ben-Hope @noxabellus dasselbe hier.

Ich habe Windows 10 auf 1809 aktualisiert und Emojis sind weg (PowerShell und Visual Studio Code; integriertes Terminal).

Siehe Befehl vue ui von vue-cli als Beispiel:
🚀 GUI starten...

Ja, ich vermisse diese kleine Rakete beim Starten des Vue-Cli 😢

@bitcrazed @zadjii-msft Gibt es ein Problem bei der Verfolgung der 1809 gefundenen Regression? Ich spreche nicht von einer vollständigen Emoji-Unterstützung, sondern nur von der Wiederherstellung der grundlegenden Fremdsprachen- / Unicode-Glyphen, die in früheren Versionen unterstützt wurden. Wissen Sie, ob das Problem in späteren Betaversionen weiterhin besteht?

Hier gilt das gleiche. Ich habe mein Win10 vor einigen Tagen von 1803 auf 1809 aktualisiert und jetzt werden alle Zeichen >= U+10000 (UTF-8 mit 4 Byte oder mehr) nicht mehr angezeigt. Ich habe auch die neueste Insider-Version ausprobiert (Windows 10 Insider Preview 18358.1 (19h1_release)), leider besteht dieser Fehler immer noch.

Da 19H1 bald veröffentlicht wird, könnten Sie es bitte beheben oder melden, da es sich um einen Fehler in einem anderen Projekt handeln könnte?

Das gleiche =(

Das Emoji-Rendering scheint sich verbessert zu haben.

Ich habe einen aktuellen Build von CascadiaPackage (Windows; x64) ausprobiert und dies erhalten (siehe Bild):

Ausführen von Windows 10, Build 1903.

Gibt es einen Vorteil, eine Option zum Deaktivieren von Farbschrift-Emojis zu haben?

Jedes verwendete Emoji wird also mit den Schriftfarbeneinstellungen einfarbig sein?

@mdtuak ja, das ist tatsächlich eine Einstellung von @miniksa und ich habe das Hinzufügen bereits besprochen. Ich habe gerade Nr. 956 eingereicht, um diese Arbeit zu verfolgen :)

@MartinMa das ist eine ganz andere Sache als die vorhandene conhost.exe. Wenn Sie versucht haben, OpenConsolePackage (das ist der OSS-Conhost) auszuführen, sollten Sie immer noch das Problem haben.

@MartinMa das ist eine ganz andere Sache als die vorhandene conhost.exe. Wenn Sie versucht haben, OpenConsolePackage (das ist der OSS-Conhost) auszuführen, sollten Sie immer noch das Problem haben.

Seien Sie sich nicht so sicher! Der DirectWrite-Renderer, der in Windows Terminal verwendet wird, _ist auch Teil von OpenConsole!_ Sie müssen nur einen Registrierungsschlüssel ( HKCU\Console\UseDx = DWORD(1) ) setzen, bevor er verwendet wird.

@DHowett-MSFT Die Konsole löst beim Einfügen einer Emoji-Zeichenfolge eine Ausnahme aus.
Es ist hier.
https://github.com/microsoft/terminal/blob/2fdcb679ab1f1f1edc542e3b86327dacea78f7ac/src/buffer/out/CharRowCellReference.cpp#L15

@DHowett-MSFT Dustin Howett FTE Die Konsole löst beim Einfügen einer Emoji-Zeichenfolge eine Ausnahme aus.
Es ist hier.
https://github.com/microsoft/terminal/blob/2fdcb679ab1f1f1edc542e3b86327dacea78f7ac/src/buffer/out/CharRowCellReference.cpp#L15

Ich bin mir zu 80-90% sicher, dass entweder @adiviness oder ich einen Fehler habe, der das schon irgendwo hier abdeckt.

Ja, die Arbeit, die ich am /dev/austdi/NewCookedRead mache, beeinflusst wahrscheinlich den Absturz dort. Wir unterstützen das Einfügen (oder Eintippen) von Emojis noch nicht in alle Shells.

@MartinMa das ist eine ganz andere Sache als die vorhandene conhost.exe. Wenn Sie versucht haben, OpenConsolePackage (das ist der OSS-Conhost) auszuführen, sollten Sie immer noch das Problem haben.

Seien Sie sich nicht so sicher! Der DirectWrite-Renderer, der in Windows Terminal verwendet wird, _ist auch Teil von OpenConsole!_ Sie müssen nur einen Registrierungsschlüssel ( HKCU\Console\UseDx = DWORD(1) ) setzen, bevor er verwendet wird.

Ich wusste es nicht einmal. Ich gehe nach Hause, um es nachts zu versuchen. Aber wirkt sich diese Registrierung auf die Standard-conhost.exe aus?

Update 2019-07-19 20:47 UTC+8

Obwohl OpenConsole DirectWrite-Rendering mit HKCU\Console\UseDx öffnen kann, scheint es immer noch keine Emojis anzuzeigen.

Vielleicht im Zusammenhang mit https://github.com/microsoft/terminal/issues/2053

Ja, es liegt mit ziemlicher Sicherheit an #2053.

@DHowett-MSFT Ist mein Commit-Fix angemessen, wenn kein Problem vorliegt, erstelle ich einen PR.

https://github.com/fcharlie/terminal/commit/4c6280ca35fff9eac0041c94385574bedc5f2a27

Ich habe dieses Youtube-Video mit @cinnamon-msft gesehen. Sie zeigte Emojis-Unterstützung. Ist das behoben? 😄

@innovoix Das ist das Windows-Terminal , hier geht es um die Windows-Konsole .

@ExE-Boss Ah OK, mein Fehler.

Als ich zum ersten Mal seit 10 Jahren eine Windows-Workstation einrichtete, die jetzt sehr an OSX gewöhnt ist, war ich sehr verstört, die geliebten und äußerst nützlichen Emojis zu verlieren. Irgendwie lustig, dass es nicht schon lange Standard ist.

Was sagten UnfundedPillow2 und ShutUpCon ? Wir werden es jetzt nie erfahren

Auch ein großes Lob an iTerm . Mögen wir Sie und Ihre Größe bald auf dieser Plattform finden. Keine geteilten Scheiben? Was für ein Schmerz 😱😱

@jasonhargrove danke für das Feedback. Vielleicht möchten Sie _Windows Terminal_ ausprobieren, das (übrigens) auch aus diesem Repository gebaut wurde. Es unterstützt die Dinge, die Sie suchen.

@jasonhargrove Wir planen, viele der Verbesserungen der Kern-Engine, die sowohl dem Windows-Terminal als auch der Windows-Konsole zugrunde liegt, in Zukunft wieder in die Windows-Konsole zu integrieren. Zu diesen Bereichen gehören der interne Textpuffer, die Text-Rendering-Engine usw. - Dinge, die sich im Allgemeinen nicht auf die Abwärtskompatibilität auswirken.

Warum der Vorbehalt "Rückwärtskompatibilität"? Die Aufgabe der Windows-Konsole (zusammen mit Cmd) besteht darin, nach Möglichkeit abwärtskompatibel zu bleiben. Daher wird es viele Funktionen (z. B. Registerkarten, geteilte Fenster usw.) geben, die nur im Windows-Terminal verfügbar sind und es nie wieder in die Konsole schaffen.

Wir empfehlen Benutzern dringend, mit der Evaluierung und dem Testen von Windows Terminal zu beginnen und alle unerwarteten Probleme hier anzugeben, damit wir sie so schnell wie möglich prüfen und beheben können, während wir Terminal in Richtung v1.0 (~2. Quartal 2020) vorantreiben.

FWIW, ab v0.7 unterstützt Windows Terminal geteilte Fenster sowie mehrere Registerkarten, UTF-8, Emoji, GPU-beschleunigtes Text-Rendering, eine Vielzahl von Konfigurationsoptionen, mehrere Verbesserungen beim Auswählen/Kopieren und Einfügen usw.

Eine Sache, die mich verrückt macht, ist die Unfähigkeit, Umschalt + Einfügen im Windows-Terminal einzufügen.

@jsilvermist Sie können shift+ins als Tastenbelegung in Ihren Terminaleinstellungen hinzufügen.

@jsilvermist Höfliche Anfrage - bitte behalten Sie Probleme in relevanten Threads. Das von Ihnen beschriebene Problem bezieht sich auf Tastenbelegungen, nicht auf Emojis ;)

@bitcrazed Stimmt, mein

Edit: obligatorisches Emoji vergessen :wink:

@jsilvermist Kein Problem - machen wir alle hin und wieder - vielen Dank 😜 👍

Emojis und Fenster im Windows-Terminal demonstrieren:

Okay, Weihnachten kommt früher! Toller Start und was für ein großer Sprung nach vorne, herzlichen Glückwunsch. Und danke, dass du mich darüber informiert hast 📈

ist es normal, ?? wenn ich das Emoji einfüge. bitte bestätigen. vielen Dank im Voraus.

@AmericanY ja, das ist ein Problem mit PowerShell 5.1.

@DHowett-MSFT das passiert auf CMD, PowerShell und Windows New Terminal .

Meine WSL druckt einige ungewöhnliche Zeichen, nachdem sie den Unicode-String gerendert hat. Ich habe versucht, ein interaktives Spiel zu erstellen und konnte die Charaktere deswegen nicht anzeigen. Sieht so aus, als ob ich mich auf 128-Bit-ASCII beschränken muss

Ich möchte nur mit Entschuldigung sagen, dass das komisch aussieht.

Ist der src-Code für fmt_test.exe irgendwo verfügbar? (Screenshot von @fcharlie weiter oben in diesem Thread) Es

@luke1961 siehe https://github.com/fcharlie/bela/blob/master/test/fmt/main.cc

Vielen Dank!

Hi,
Um den Kommentar von @AmericanY hinzuzufügen , wird beim Einfügen eines Windows-Terminal die Eingabe in der Eingabe unterbrochen und in der Ausgabe korrigiert.
Auch wenn direkt danach ein Pfeil nach oben ausgeführt wird, ist dies diesmal richtig in der Eingabe.

Ist dies zu erwarten?

Windows-Terminal
Powershell-Kern 6.2.1
Meslo LG M für Powerline

@AmericanY ja, das ist ein Problem mit PowerShell 5.1.

Abgesehen davon wird der Abstand zwischen zwei Emojis in noble 5.1 in Linefeed umgewandelt, aber nicht in anderen Shells wie ash, bash und so weiter:

@remidebette Du wirst #1503 sehen wollen

@zadjii-msft , das scheint ziemlich schwer zu sein, wird aber wirklich nett sein, wenn Sie es einmal knacken.
Halte durch!

Ich habe Emoji auf einigen Shells unter Windows Terminal (Version: 0.11.1191.0) getestet und hier sind die Ergebnisse:

• CMD
  
• Power Shell
  
• Befehlshaber
  
• WSL mit ZSH
  
• Cygwin mit ZSH
  

Sieht so aus, als ob die einzige Shell, die bisher perfekt funktioniert, WSL (sowohl bash als auch zsh) ist...

Ich arbeite mit einem alten Satz von Informationen, aber es war zumindest so, dass die Konsole die Prompt-Zeile in einem separaten Puffer vom Ausgabepuffer speichert und nicht mehr als die ucs2-Codierung unterstützte. WSL funktioniert, weil es in utf8 kodiert ist. Ich habe einmal an einer Filiale gearbeitet, die das Problem behoben hat, wenn ich dieses Wochenende die Zeit finde, werde ich einen Blick darauf werfen. Hmm

Bearbeiten: WSL könnte auch funktionieren, wenn es nicht das gekochte Lesen wie die anderen verwendet, ich erinnere mich nicht, ob es dies tut oder nicht.

Wie kann ich das Emoji reparieren?

Ich stoße auf das gleiche Problem; es scheint keine aktuelle lösung afaik zu sein.

Süss! Ein weiterer Anwendungsfall: Ich habe eine Kommandozeilen-App, die Warnungen mit ⚠ ausgibt.

Die Ausgabe von Emoji funktioniert meiner Erfahrung nach gut.

Es kann also sicher sein, dass das Problem darin besteht, dass eingegebene Zeichen im Windows-Terminal nicht richtig wiedergegeben werden. Ich habe Git Bash (eine Art von Shell) ausprobiert. Es funktioniert gut mit der Git Bash-GUI, funktioniert jedoch nicht mit dem Windows-Terminal wie bei den anderen erwähnten Fehlern.

1. Git Bash-GUI
   
2. Git-Bash mit Windows-Terminal
   

Meine Windows-Terminalversion ist 1.1.2233.0.
Hoffe konnte es so schnell wie möglich beheben! 👍 Und gibt es einen voraussichtlichen Zeitplan?

Bitte melden Sie einen separaten Fehler für dieses Problem und fügen Sie den Inhalt Ihrer Windows-Terminal-Einstellungsdatei hinzu.

Bitte melden Sie einen separaten Fehler für dieses Problem und fügen Sie den Inhalt Ihrer Windows-Terminal-Einstellungsdatei hinzu.

Ich habe das gleiche Problem:
{ "guid": "{00000000-0000-0000-ba54-000000000002}", "acrylicOpacity": 0.75, "closeOnExit": true, "colorScheme": "Campbell", "commandline": "\"%PROGRAMFILES%\\git\\usr\\bin\\bash.exe\" -i -l", "cursorColor": "#FFFFFF", "cursorShape": "bar", "fontFace": "Consolas", "fontSize": 10, "historySize": 9001, "icon": "%PROGRAMFILES%\\Git\\mingw64\\share\\git\\git-for-windows.ico", "name": "Bash", "padding": "10, 0", "snapOnInput": true, "startingDirectory": "%USERPROFILE%", "useAcrylic": true },
Windows-Terminal: v1.3.2651.0
Git: v2.16.2.windows.1