Xterm.js: Manipulação de Unicode em xterm.js

Criado em 25 set. 2018 · 10Comentários · Fonte: xtermjs/xterm.js

Vindo do # 1707, parece que o manuseio correto do unicode é cada vez mais um problema para as pessoas devido aos emojis. Como todos nós amamos emojis, isso deve ser corrigido o mais rápido possível :smile:

Proposta:
Crie um provedor para diferentes versões de unicode, que seja capaz de ocultar os dados e implementações específicos da versão por trás de uma boa API. Atualmente, só precisamos de implementações dependentes de versão para wcwidth, portanto, um esboço aproximado pode ficar assim:

interface IUnicodeProvider {
  supportedVersions(): string[];
  getVersion(): string;
  setVersion(version?: string);  // version optional for fallback behavior
  wcwidth(ucs: number): number;
  getStringCellWidth(s: string): number;
  ... // more to come with support of other unicode features
}

Idealmente, o provedor é autocontido, portanto, o terminal precisa apenas lidar com os métodos de interface e atualizar a versão/localidade quando necessário. O provedor teria que lidar com o material de baixo nível para fornecer os conjuntos de dados corretos para que os métodos funcionassem conforme o esperado para uma versão com suporte.
Dentro do provedor, podemos decidir se os dados são fornecidos estaticamente na base de código ou até mesmo se tentamos criar os dados em tempo real. O primeiro terá um grande impacto no tamanho do xterm.js, o segundo levantará questões assíncronas (lembre-se - a maioria das partes principais são atm síncronas). Todo o material unicode também pode ser empacotado em algum complemento como recurso para a versão XY.

Pronto para discussão.
/cc @Tyriar , @bgw , @mofux , @dnfield

areparser typenhancement

Fonte

jerch

👍11

Comentários muito úteis

Nova tentativa em https://github.com/xtermjs/xterm.js/pull/2568 , espero que possamos lançar isso na próxima versão.

jerch em 6 dez. 2019

🎉7

Todos 10 comentários

Acho que algo assim pode ser mais acessível:

interface IUnicodeProvider {
  getVersion(): string;
  wcwidth(ucs: number): number;
  getStringCellWidth(s: string): number;
  ... // more to come with support of other unicode features
}

Com algo como UnicodeProviderFactory.v11 seria um pouco melhor na hora da codificação, mas isso faz sentido para mim de qualquer maneira.

dnfield em 25 set. 2018

@dnfield Sim, de qualquer maneira funcionará. Não tenho certeza se precisaremos das informações de tipo no nível da versão.

Minha ideia era criar uma interface, que pudesse fazer as trocas de versão de forma transparente em tempo de execução assim:

// terminal ctor - create the provider
this.unicodeProvider = new UnicodeProvider();
...
// some code that knows whether to switch unicode versions
this.unicodeProvider.setVersion(xy);
...
// some unicode consumer - does not care about versions at all, just gets the right method
this.unicodeProvider.wcwidth(...)

Dessa forma this.unicodeProvider pode ser transportado sem a necessidade de reconectar após uma alteração de versão ou usando uma propriedade cara na instância do terminal.

jerch em 25 set. 2018

O que eu recebo da discussão em #1707:

Queremos entregar duas versões de tabela wcwidth por enquanto, a antiga e a nova criada por @dnfield.
Caracteres ambíguos não valem a pena, como @gnachman apontou. Eles são tratados com meia largura pela maioria dos aplicativos, então podemos fazer o mesmo (já feito na tabela legada, precisa ser testado com a nova tabela).
Crie uma nova opção global para a versão unicode. A opção teria que ser definida pelos integradores ou oferecida aos usuários para alterações no tempo de execução.
Adiar a criação de uma nova sequência de escape para definir a versão unicode, pois ainda não foi estabelecida uma interface para registro de sequências não padrão.
Nenhum adivinhador mágico de versão unicode por enquanto. Assim que fizermos essa ferramenta no futuro, ela estará fora do xterm.js de qualquer maneira (talvez ela possa residir na organização como um pacote separado).
No futuro, talvez precisemos criar complementos unicode para manter o tamanho do pacote de xterm,js pequeno.

Algum comprador para colocar isso no código TS?

jerch em 28 set. 2018

👍1

Fez uma primeira encarnação possível em #1714. Copiei a nova tabela do #1707, espero que esteja tudo bem (@dnfield).

jerch em 28 set. 2018

👍1

Sem problemas!

dnfield em 28 set. 2018

❤1

https://github.com/xtermjs/xterm.js/pull/1714 é uma boa referência para isso, mas o plano é enviar vários addons após o novo modelo de addon (https://github.com/xtermjs/xterm. js/issues/1128) está, então permita que o incorporador escolha a versão correta.

Tyriar em 10 mai. 2019

Por favor, corrija o mais rápido possível, atualizar o Windows recentemente pareceu quebrar isso para mim. Estou tentando oferecer suporte a uma biblioteca Node.js que emoji'fies alguns aspectos do log para facilitar a leitura (parece muito mais bobo do que é).