Editor de texto rico quebra recurso de Substituição de Texto em plataformas Apple

Os fóruns que modero recentemente mudaram para usar o novo editor de rich text e, imediatamente, percebi que ele parece (de certa forma) quebrar recursos de substituição de texto do sistema operacional, como Geral > Teclados > Substituição de Texto no iOS. Isso é lamentável porque tenho várias substituições que uso muito no Discourse. Por exemplo, uma das minhas tarefas de moderação mais comuns é redirecionar usuários para outros fóruns, e por isso tenho, por exemplo, uma substituição de texto que substitui adf por um link para os fóruns de desenvolvedores da Apple. (Prefiro não usar respostas prontas para isso porque a maior parte do restante da postagem geralmente não é um modelo, mas sempre contém esse link. Além disso, tenho várias outras substituições que não se encaixam nesse modelo.)

Curiosamente, algumas das minhas substituições continuam funcionando; por exemplo, \\tau parece se transformar de forma confiável em τ. E minha substituição adf parece funcionar quase que totalmente se eu a digitar entre crases: estou escrevendo esta postagem no Safari do macOS, e [crase] adf [crase] [espaço] resulta brevemente em [Apple Developer Forums](https://forums.developer.apple.com/), embora isso desapareça e volte a ser adf se eu interagir com o editor de alguma forma depois.

Presumo que a barra invertida inicial deva ter algo a ver com o motivo pelo qual isso está funcionando para minhas outras substituições, então provavelmente posso contornar esse bug alterando minha substituição adf para \\adf. Mas eu realmente não deveria ter que fazer isso.

Este é um problema bastante sério para mim, pois está interferindo na minha capacidade de realizar esse tipo de moderação de forma eficiente a partir do aplicativo iOS do Discourse. (É por isso que também não quero ter que adicionar uma barra invertida inicial: é irritante digitar uma barra invertida em um teclado de celular.)

1 curtida

Talvez esta seja uma solicitação de recurso, mas acho que você só precisará clicar no image para voltar ao editor Markdown se quiser usar tais personalizações.

Claro, apenas usar o editor de markdown é uma solução alternativa aceitável. Considere isso uma solicitação de recurso para que a funcionalidade funcione de forma consistente em todos os modos de edição, então. Novamente, o editor de rich text nem sempre ignora essas substituições — imagino que elas sejam iniciadas pelo sistema operacional de alguma forma — ele apenas tende a lidar mal com elas.

2 curtidas

Suspeito que esta seja a classe de problema em que estamos pré-processando a área de transferência para segurança.

Colar [test] no compositor de rich text resulta em \\[test\\] no modo bruto

Da mesma forma, colar:

\u003ca href=\"apple.com\"\u003eapple\u003c/a\u003e

resulta em apple no RTE (não um link)

mas resulta em \u003ca href="apple.com"\u003eapple\u003c/a\u003e se você colar no modo bruto


Parece altamente relacionado @renato?

2 curtidas

Isso me parece um bug, provavelmente na nossa lógica de criar um link ao colar sobre uma seleção. Vou dar uma olhada.

Substituições de texto no iOS podem ser semelhantes ao IME do Android, ignorando os eventos de inserção de texto esperados. Não tenho certeza, mas parece ser um problema diferente.

Não é impossível que essas ocorrências inconsistentes estejam sendo causadas por um erro de tempo de execução. Tentarei reproduzi-lo esta semana.

3 curtidas