Como criar um editor que não corrompe a composição de texto em coreano

Ao escrever em coreano, às vezes nos deparamos com situações estranhas. Um caractere desaparece no fim da linha e, depois de passar para outra janela e voltar, a última sílaba é inserida duas vezes. Às vezes, o cursor também se move para um lugar inesperado durante a digitação.

No início, é fácil pensar que o erro foi nosso. Mas, na maioria das vezes, o problema não está nas mãos. Isso acontece porque o editor não lida corretamente com a “composição” do hangul.

Para inserir um único caractere em hangul, é preciso pressionar várias consoantes e vogais. Antes de a sílaba ficar completa, ela aparece na tela, mas ainda não é um caractere confirmado. Esse estado é chamado de composição.

É um estado raro em inglês, mas, ao escrever em coreano, estamos quase sempre no meio de uma composição. Por isso, mesmo um pequeno problema no processamento da composição causa um grande incômodo para quem usa o coreano.

Basta observar os problemas publicados. No Typora, há um problema em que palavras em coreano são inseridas separadas no macOS (#4251) e outro em que o cursor salta durante a composição (#788). No Obsidian, há um problema em que caracteres coreanos desaparecem aleatoriamente no Ubuntu (#79528), outro em que não é possível digitar em coreano no Wayland (#84391) e uma publicação no fórum relatando que a entrada é ignorada no ponto de quebra de linha (#114224).

Embora os aplicativos fossem diferentes, o ponto em comum era semelhante. O editor reinterpretava os eventos de composição sobre o mecanismo do navegador.

Caracteres não confirmados não entram no documento

O shell Linux do mote não interpreta diretamente a composição do hangul. A tarefa de transformar consoantes e vogais em sílabas fica a cargo do método de entrada do sistema operacional.

Os caracteres em composição aparecem apenas na tela. Eles só entram no documento depois que a sílaba é confirmada.

Esse único princípio eliminou vários problemas.

Não é criado um registro de desfazer a cada etapa da composição. O salvamento automático também não grava no arquivo uma sílaba ainda incompleta. E os recursos de Markdown não tentam formatar caracteres que ainda não foram confirmados.

Ao pensar no salvamento automático, a diferença fica ainda mais clara. Durante a digitação em coreano, uma sílaba pode estar em composição até mesmo em uma breve pausa. Se o caractere em composição entrasse no documento, uma sílaba incompleta poderia ser salva. Ao pressionar desfazer uma vez, também poderia ser apagado apenas um jamo.

Quando a composição é mantida fora do documento, não é necessário tratar essas exceções separadamente. Afinal, um caractere ainda não confirmado ainda não faz parte do documento.

A tela não se move nem durante a digitação

No início, removemos toda a formatação Markdown da linha em composição. Parecia seguro, mas isso criou um novo problema.

Ao digitar em coreano em um título, a linha de repente diminuía para o tamanho do corpo do texto. Ela só voltava a ser um título depois que a digitação terminava. Como quem usa o coreano digita compondo caracteres continuamente, a altura da linha também subia e descia o tempo todo durante a escrita.

Agora, o caractere em composição é calculado exatamente como aparece inserido na linha. Ao digitar um título, o estilo do título também é mantido na sílaba em composição. Ao digitar dentro de um trecho em negrito, o peso também não muda. Os símbolos ocultos de Markdown tampouco cobrem o caractere em composição.

Também removemos o sublinhado azul que aparecia sob os caracteres em composição. Isso porque, durante toda a escrita em coreano, parecia que a parte de baixo da frase estava piscando. Mesmo sem o sublinhado, o recurso de composição continua funcionando normalmente.

Isso não é um simples efeito visual. Mesmo que todos os caracteres sejam inseridos, se a linha continuar se movendo, o fluxo da escrita é interrompido. A tela precisa permanecer tranquila para que seja possível se concentrar na frase.

Em vez de dizer “há suporte ao coreano”, verificamos o comportamento real

Dizer apenas “há suporte ao coreano” não é suficiente.

Não dá para saber se basta que os caracteres sejam inseridos ou se a tela também precisa permanecer estável durante a digitação. Também é difícil verificar se, depois de passar para outra janela e voltar, a última sílaba não desaparece nem é inserida duas vezes.

Por isso, o mote transformou uma promessa vaga em itens concretos de verificação. A cada lançamento, digitamos diretamente em coreano usando um método de entrada real e uma tela real. Verificamos 12 condições em 9 situações, e um script salva os resultados em um arquivo. Na execução mais recente, todas as 12 condições foram aprovadas.

Os itens de verificação também não foram criados com base em suposições. Eles foram definidos a partir de problemas de entrada em coreano publicados em outros editores e de telas do mote em que problemas poderiam realmente ocorrer.

Verificamos se o cursor não se move ao digitar dentro de um trecho enfatizado. Também conferimos se a última sílaba é confirmada exatamente uma vez ao passar para outra janela e voltar. Testamos ainda a situação de digitar em coreano na janela de busca e depois retornar à tela de edição. E repetimos o mesmo processo em células de tabela, na linha seguinte a uma lista e em títulos.

Os testes são específicos. Por exemplo, ao pressionar Enter durante a composição de uma sílaba, a sílaba concluída deve permanecer na primeira linha, e somente o novo jamo digitado deve ir para a segunda linha. Ao pressionar Backspace uma vez durante a composição de ‘한’, o caractere não deve desaparecer por completo, mas se transformar em ‘하’.

Se jamos e caracteres completos forem confundidos, o teste falha imediatamente.

Não dizemos que um ambiente é compatível sem tê-lo verificado

O ambiente verificado diretamente a cada lançamento é a combinação de X11 e ibus no shell Linux.

No Wayland e no fcitx5, verificamos o funcionamento básico da composição em oito ambientes experimentais separados. No entanto, o escopo dos testes não é o mesmo. Os shells para macOS e Windows também ainda estão em desenvolvimento. Não afirmamos que os métodos de entrada de cada sistema operacional são compatíveis antes de concluir a verificação.

Também há problemas que o mote não pode corrigir. Um exemplo típico é o comportamento em que o método de entrada inicia no modo inglês sempre que uma nova janela de entrada é aberta. Depois de fechar a janela de busca e voltar à tela de edição, talvez seja necessário pressionar novamente a tecla de alternância entre coreano e inglês.

Esse problema ocorre de forma geral em aplicativos GTK e pode ser alterado nas configurações do método de entrada. Não descrevemos como nosso um bug que não é nosso. Em vez disso, indicamos onde essa configuração está localizada.

Um editor em que é possível digitar em coreano é diferente de um editor bom para escrever em coreano.

No primeiro, os caracteres entram. No segundo, o texto não se move nem mesmo enquanto se digita.