Terminal: Adicionar suporte para emoji ao console do Windows

Já está no backlog :)

Doce! Outro caso de uso: tenho um aplicativo de linha de comando que emite avisos usando ⚠.

@ zadjii-msft isso incluirá suporte para caracteres Unicode não latinos? ou seja, os caracteres árabes ou japoneses não encontrados na fonte do console atualmente implantada podem ser exibidos com uma fonte diferente?

Hipoteticamente, sim.

Árabe é um problema - não há quase nenhuma chance de implementarmos o suporte ao idioma da esquerda para a direita em breve, mas os caracteres podem ser renderizados corretamente.

@adiviness pode falar mais sobre o assunto se houver mais para compartilhar.

O árabe é difícil por causa do suporte adicional necessário para texto bidirecional e ligaduras. Pelo que eu sei, não há muitos emuladores de terminal que o suportem atualmente.

Também há uma diferença entre o console ser capaz de renderizar emoji e suportar fallback de fonte no caso da fonte atual não ter um glifo. Ambos são itens de nossa carteira.

+1 Nossos scripts de construção e CI têm emojis para o sucesso ✔️, aviso ⚠ e erros ❌ para visualização rápida e produtiva dos logs.

Podemos não marcar problemas com +1? Por favor, use reações ou assine notificações.

@miniksa , eu não me distrairia muito com o +1. Você pode ignorá-lo totalmente. O principal objetivo da digitação era articular o caso de uso. Presumivelmente, os proprietários de plataforma / produto devem estar muito interessados ​​nos casos de uso do cliente ... pensamento concedido, neste caso, não é muito extravagante.

@SidShetye - agradeço seu comentário - seu caso de uso não é incomum, mas é útil ouvir sobre.

Em geral, pedimos às pessoas que não marquem com +1 porque gostaríamos de evitar que as pessoas marcassem com +1 (especialmente sem comentários adicionais), o que acaba sendo um ruído e torna os tópicos mais difíceis de analisar e gerenciar.

Compartilhar comentários adicionais, contexto, observações, questões, etc. é MUITO mais valioso do que +1;)

Estranho que ninguém tenha mencionado isso, mas o gerenciador de pacotes Yarn usa Emoji e é um pouco chato que eles sejam exibidos apenas como quadrados: /

Obrigado @ destructive-dragon - há muitas ferramentas que contêm / emitem emojis, mas o console ainda não é capaz de renderizá-los.

@bitcrazed Você mencionou neste tópico do Twitter no lançamento do conpty que ainda precisamos esperar por um novo buffer e um novo renderizador (DirectWrite). Esses são os únicos dois grandes bloqueadores que restam?

@kavdev Essencialmente, sim. Para exibir glifos de emoji, primeiro temos que ser capazes de armazenar (potencialmente compostos) pontos de código Unicode para cada glifo (por exemplo, Ninjacats), mas também devemos ser capazes de renderizá-los, o que requer fallback de fonte, o que GDI não faz suporte t.

Estaremos trabalhando em melhorias na implementação do buffer de texto do Console e também no Renderer em versões futuras.

@bitcrazed
Muitos Emoji são compostos, ou seja, têm vários pontos de código unidos (usando ZWJ ou VS ou qualquer outro) e, na maioria dos casos, eles não cabem em uma célula do Console. Portanto, o seu problema não é "1 célula para n caracteres", mas "m células para n caracteres" ...

FWIW, meu emulador de terminal e iTerm2 renderizam emoji basicamente tratando-os como caracteres de estilo CJK de "largura total" (2 células). Não sei sobre o iTerm2, mas não faço qualquer tentativa de oferecer suporte a "modificadores" de Unicode em emoji ou quaisquer outros caracteres. Cada caractere deve ser um ponto de código Unicode, embora possa ter largura normal ou largura total.

@ sedwards2009
A solução definitiva deve ser um Unicode ou qualquer especificação que nos diga como lidar com scripts complexos em uma grade de caracteres.

A ideia mais próxima pode ser a aplicação de alguns conceitos de justificação (como inserir espaços entre caracteres do Leste Asiático e inserir Kashida ao ajustar caracteres árabes na grade), mas a implementação da justificação é uma bagunça total. AFAIK DWRITE faz o melhor trabalho até agora, mas algumas implementações (como Kashida) ainda são muito hacky.

Apenas um comentário que pode ser útil - certos símbolos emoji e Unicode costumavam funcionar , eu exibia alguns no meu banner de login WSL, por exemplo, 🍰 (U + 1F370), desde a atualização de 1809 eles não são mais exibidos em nenhum terminal (WSL bash, Hyper, VS Code)
No entanto, alguns símbolos funcionam em 1809, como ☕ (U + 2615), mas acho que eles estão em partes diferentes do espectro Unicode, ou seja, pontos de código muito mais baixos

A atualização de outubro parece trazer uma regressão a este respeito, em vez de progresso. Anteriormente, eu era capaz de usar todos os símbolos Unicode que testei no terminal integrado do VS Code (que usa PowerShell), no entanto, após a atualização de outubro, todos os emoji e alguns caracteres de idioma estrangeiro não são renderizados corretamente.

Na verdade, isso parece ser um problema de fonte do sistema todo, já que até emuladores de console como o ConEmu agora falham em renderizar os emojis corretamente.

@Ben-Hope @noxabellus mesmo aqui.

Atualizei o Windows 10 para 1809 e os emojis sumiram (PowerShell e Visual Studio Code; terminal integrado).

Veja o comando vue ui de vue-cli como exemplo:
🚀 Iniciando GUI ...

Sim, sinto falta daquele pequeno foguete ao iniciar o vue-cli 😢

@bitcrazed @ zadjii-msft há um problema ao rastrear a regressão encontrada em 1809? Não estou falando sobre suporte total a emojis, apenas obter de volta os glifos básicos de idioma estrangeiro / Unicode que eram suportados em versões anteriores. Você sabe se o problema persiste em versões beta posteriores?

Mesmo aqui. Atualizei meu Win10 de 1803 para 1809 há vários dias e agora todos os caracteres> = U + 10000 (UTF-8 com 4 bytes ou mais) não são mais exibidos. Também experimentei a versão interna mais recente (Windows 10 Insider Preview 18358.1 (19h1_release)), infelizmente, esse bug ainda existe.

Já que 19H1 será lançado em breve, você poderia corrigir ou relatar porque pode ser um bug em outro projeto?

Mesmo = (

A renderização de emojis parece ter melhorado.

Tentei uma compilação recente de CascadiaPackage (Windows; x64) e consegui (veja a imagem):

Executando o Windows 10, Build 1903.

Há algum mérito em ter a opção de desativar o emoji de fonte colorida?

Então, qualquer emoji usado terá uma única cor usando as configurações de cor da fonte?

@mdtuak sim, na verdade essa é uma configuração que @miniksa e eu já discutimos a adição. Acabei de preencher o número 956 para rastrear esse trabalho :)

@MartinMa é uma coisa totalmente diferente do conhost.exe existente, se você tentou executar o OpenConsolePackage (que é o conhost do OSS), ainda deve ter o problema.

@MartinMa é uma coisa totalmente diferente do conhost.exe existente, se você tentou executar o OpenConsolePackage (que é o conhost do OSS), ainda deve ter o problema.

Não tenha tanta certeza! O renderizador DirectWrite que é usado no Windows Terminal _também faz parte do OpenConsole! _ Você só precisa definir uma chave de registro ( HKCU\Console\UseDx = DWORD(1) ) antes de usá-lo.

@ DHowett-MSFT O console lança uma exceção ao colar uma string de emoji.
Está aqui.
https://github.com/microsoft/terminal/blob/2fdcb679ab1f1f1edc542e3b86327dacea78f7ac/src/buffer/out/CharRowCellReference.cpp#L15

@ DHowett-MSFT Dustin Howett FTE O console lança uma exceção ao colar uma seqüência de emoji.
Está aqui.
https://github.com/microsoft/terminal/blob/2fdcb679ab1f1f1edc542e3b86327dacea78f7ac/src/buffer/out/CharRowCellReference.cpp#L15

Tenho 80-90% de certeza de que @adiviness ou tenho um bug que já cobre isso em algum lugar por aqui.

Sim, o trabalho que estou fazendo no /dev/austdi/NewCookedRead provavelmente afeta o acidente lá. Ainda não oferecemos suporte para a colagem (ou digitação) de emojis em todos os shells.

@MartinMa é uma coisa totalmente diferente do conhost.exe existente, se você tentou executar o OpenConsolePackage (que é o conhost do OSS), ainda deve ter o problema.

Não tenha tanta certeza! O renderizador DirectWrite que é usado no Windows Terminal _também faz parte do OpenConsole! _ Você só precisa definir uma chave de registro ( HKCU\Console\UseDx = DWORD(1) ) antes de usá-lo.

Eu nem sabia. Vou para casa experimentar à noite. Mas esse registro afeta o conhost.exe padrão?

Atualização 19/07/2019 20:47 UTC + 8

Embora o OpenConsole possa abrir a renderização DirectWrite com HKCU\Console\UseDx , ele ainda parece não ser capaz de exibir emoji.

Talvez relacionado a https://github.com/microsoft/terminal/issues/2053

Sim, é quase certo por causa do # 2053.

@ DHowett-MSFT Minha correção de commit será apropriada? Se não houver problema, criarei um PR.

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

Eu vi este vídeo no Youtube com @ cinnamon-msft. Ela mostrou apoio a emojis. Isso está consertado? 😄

@innovoix Esse é o Terminal do Console do

@ ExE-Boss Ah OK, meu mal.

Quando configurei uma estação de trabalho Windows pela primeira vez em 10 anos, agora muito acostumada com o OSX, fiquei muito perturbada por perder os amados e extremamente úteis emojis. Meio engraçado, não é um padrão há muito tempo.

O que UnfundedPillow2 e ShutUpCon estavam dizendo? Agora nunca saberemos 😢😢

Também grite bem para iTerm . Que possamos encontrar você e sua grandeza nesta plataforma em breve. Sem painéis divididos? Que dor 😱😱

@jasonhargrove obrigado pelo feedback. Você pode querer verificar o _Windows Terminal_, que (aliás) também é construído a partir deste repositório. Suporta o que você está procurando.

@jasonhargrove Planejamos integrar muitas das melhorias ao mecanismo principal subjacente ao Terminal do Windows e ao Console do Windows de volta ao Console do Windows no futuro. Essas áreas incluem o buffer de texto interno, mecanismo de renderização de texto, etc. - coisas que geralmente não afetam a compatibilidade com versões anteriores.

Por que a ressalva "compatibilidade com versões anteriores"? O trabalho do Console do Windows (junto com o Cmd) é permanecer compatível com as versões anteriores sempre que possível. Assim, haverá muitos recursos (por exemplo, guias, painéis divididos, etc.) que estarão disponíveis apenas no Terminal do Windows e nunca voltarão ao Console.

Recomendamos fortemente que os usuários comecem a avaliar e testar o Terminal do Windows, arquive todos os problemas inesperados aqui para que possamos fazer a triagem e corrigi-los o mais rápido possível enquanto conduzimos o Terminal para a v1.0 (~ Q2 2020).

FWIW, a partir da v0.7 Windows Terminal DOES suporta painéis divididos , bem como várias guias, UTF-8, emoji, renderização de texto acelerada por GPU, um grande número de opções de configuração, várias melhorias de seleção / copiar e colar, etc.

Uma coisa que me deixa louco é a incapacidade de Shift + Insert colar no Terminal do Windows.

@jsilvermist, você pode adicionar shift+ins como um atalho de tecla nas configurações do Terminal.

@jsilvermist Solicitação conversas relevantes. O problema que você descreve está relacionado a atalhos de teclado, não a emoji;)

@bitcrazed Verdade, meu mal! Além disso, obrigado @ DHowett-MSFT!

Edit: esqueci o emoji obrigatório: wink:

@jsilvermist Sem problemas - todos nós fazemos isso de vez em quando - muito obrigado 😜 👍

Demonstrando emojis e painéis no Terminal do Windows:

Ok, o Natal chega mais cedo! Ótimo começo para isso e que grande salto em frente, parabéns. E obrigado por me informar sobre isso 📈

é normal ver ?? se eu colar o emoji. por favor confirme. desde já, obrigado.

@AmericanY sim, este é um problema com o PowerShell 5.1.

@ DHowett-MSFT que acontece no CMD, PowerShell e novo terminal do Windows.

Meu WSL está imprimindo alguns caracteres incomuns depois de renderizar a string Unicode. Eu estava tentando construir um jogo interativo e não consegui exibir os personagens devido a isso. Parece que tenho que me restringir ao ASCII de 128 bits

Só quero dizer, com desculpas, que isso parece hilário.

O código src para fmt_test.exe está disponível em algum lugar? (captura de tela por @fcharlie anteriormente neste tópico) Estou tendo dificuldade em duplicar o resultado.

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

Obrigado!

Oi,
Para adicionar o comentário de @AmericanY , ao colar no Terminal do
Além disso, se fizer uma seta para cima logo depois, está correto na entrada desta vez.

Isso é esperado?

Terminal Windows
Powershell Core 6.2.1
Meslo LG M para Powerline

@AmericanY sim, este é um problema com o PowerShell 5.1.

Além desse, o espaço entre dois emojis é convertido para linefeed no posh 5.1, mas não em outros shells como ash, bash e assim por diante:

@remidebette, você vai querer ver # 1503

@ zadjii-msft, isso parece muito difícil, mas será muito bom quando você quebrá-lo.
Mantenha-se firme!

Testei o emoji em alguns shells no Terminal do Windows (versão: 0.11.1191.0) e aqui estão os resultados:

• CMD
  
• Powershell
  
• Comandante
  
• WSL com ZSH
  
• Cygwin com ZSH
  

Parece que o único shell que funciona perfeitamente até agora é o WSL (bash e zsh) ...

Estou trabalhando com um conjunto antigo de informações, mas pelo menos costumava ser que o console armazenava a linha de prompt em um buffer separado do buffer de saída e não suportava mais do que a codificação ucs2. WSL funciona bc é codificado em utf8. Eu estava trabalhando em uma filial em um ponto que consertou isso, se eu encontrar tempo neste fim de semana, vou dar uma olhada. Hmm

edit: WSL também pode estar funcionando se não usar a leitura cozida como as outras, não me lembro se usa ou não.

Como posso consertar o emoji?

Estou encontrando o mesmo problema; não parece um afaik de solução atualizada.

Doce! Outro caso de uso: tenho um aplicativo de linha de comando que emite avisos usando ⚠.

A saída de Emoji funciona bem na minha experiência.

Portanto, pode-se ter certeza de que o problema é que os caracteres de entrada não são renderizados corretamente no terminal do Windows. Eu tentei Git Bash (um tipo de shell), ele funciona bem com a GUI do Git Bash, mas não funciona com o terminal do Windows, como os bugs mencionados entre outros.

1. GUI do Git Bash
   
2. Git Bash com Terminal Windows
   

Minha versão do terminal do Windows é 1.1.2233.0.
Espero que consiga consertar o mais rápido possível! 👍 E existe um cronograma estimado?

Registre um bug separado para esse problema e inclua o conteúdo do arquivo de configurações do Terminal do Windows.

Registre um bug separado para esse problema e inclua o conteúdo do arquivo de configurações do Terminal do Windows.

Eu tenho o mesmo problema:
{ "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 },
Terminal Windows: v1.3.2651.0
Git: v2.16.2.windows.1