Pontuação Inteligente sem Símbolos IP

Seria possível ajustar as configurações atuais do tipógrafo Markdown (também conhecido como “pontuação inteligente”) para habilitar sinais de pontuação Unicode, como aspas e travessões, mas desabilitar (c), ™ e, potencialmente, outros glifos especializados desse tipo?

Sou advogado. Atuo frequentemente em questões de marcas registradas e direitos autorais, inclusive em fóruns do Discourse. Ainda não aconselhei ninguém a revisar uma postagem para adicionar um símbolo de direitos autorais ou de marca registrada, e leigos tendem a superestimar massivamente a frequência com que esses símbolos são úteis ou necessários. Por outro lado, editei mais postagens do que consigo contar na tentativa de enganar o renderizador Markdown para que ele não renderize o símbolo ©.

Isso surge com especial frequência em listas enumeradas. Por exemplo:

(a) maçã
(b) banana
(c) direito autoral?
(d) data

Esse estilo de enumeração é muito comum em leis, contratos, políticas e outras redações formais influenciadas pelo estilo jurídico. Também é um estilo de tópicos muito comum. Fazia parte do estilo de tópicos “padrão” que me ensinaram quando era aluno do ensino fundamental nos Estados Unidos.

Vejo que as configurações atuais oferecem certa flexibilidade em torno da pontuação, mas, até onde posso ver, não há nenhuma maneira de habilitar a pontuação inteligente sem também habilitar os símbolos inteligentes.

9 curtidas

Não tenho opiniões fortes sobre isso. Acredito que a necessidade de digitar o símbolo de direitos autorais é tão rara que esse atalho pode ser mantido. O equilíbrio entre a utilidade extremamente rara e o formato da lista (a) (b) (c) — que é bastante comum, mas pouco elegante — me parece aceitável. Estou de acordo em remover completamente esse atalho em particular, @sam.

6 curtidas

Eu também apoiaria simplesmente remover o (c).

Não é como se fosse difícil pesquisar por “símbolo de copyright”, copiar e colar. Nerds podem digitar ©.

Do ponto de vista da usabilidade, eu teria uma lista com todas as expansões. Suspeito fortemente que elas sejam mais surpreendentes do que úteis.

5 curtidas

Certo, para este caso, o benefício (mi-mi-núsculo) parece superar o risco (bastante considerável!).

5 curtidas

Isso não parece ser tão configurável. Seria necessário aplicar um patch no markdown.it para suportar essa flexibilidade ou simplesmente criar nossa própria versão baseada no prettify a partir do markdown.it.

A única correção trivial é desativar todo o recurso.

5 curtidas

Huh, estranho que não seja configurável de forma alguma. Que pena. Então

(c) (tm) (r) (p) → (c) ™ (r) (p)

3 curtidas

O lado bom é que o motor é bastante configurável: podemos desativar as regras no markdown.it, copiar o código e implementar nossas próprias substituições, assim como o @Roman implementou.

Alguns dias de engenharia para limpar isso também seriam necessários; seria uma pena enviar o mesmo código duas vezes, mas é meio inevitável se formos fazer um fork dele.

3 curtidas

A partir do commit 7b8969ce5cb2edc54f2c1aa39a85a3a08076337d na master do markdown-it, o arquivo de origem relevante é lib/rules_core/replacements.js e o fixture de teste relevante é test/fixtures/markdown-it/typographer.txt.

Todas as substituições estão codificadas diretamente. Elas incluem (c) → (c), (tm) → ™, (r) → (r) e (p) → (p), que são agrupadas como “abreviações escopadas”.

Por que não, não obtenho (p) para §. Isso quase certamente deveria ser ℗, o símbolo de fonograma, em vez disso.

Vou investigar isso por um tempo e ver se consigo criar um patch que torne o recurso “typographer” mais configurável.

7 curtidas

Isso também me deixa louco. Eu esbarro nisso pelo menos uma vez por semana.

9 curtidas

Primeiro, PR complementar, corrigindo a interpretação de (p) e (P): Fix typographer interpretation of `(p)` by kemitchell · Pull Request #761 · markdown-it/markdown-it · GitHub

7 curtidas

PR para desativar grupos de substituições: Configurable typographer by kemitchell · Pull Request #762 · markdown-it/markdown-it · GitHub

3 curtidas

O mantenedor é extremamente responsivo. Ele fecha meus PRs em questão de minutos :stuck_out_tongue_winking_eye:

O que estou lendo é que ele reluta muito, muito em introduzir qualquer mudança quebradora, mesmo em novas versões principais, até mesmo para coisas como a renderização de (P) como §. Ele também é alérgico a permitir opções no estilo typographer: {A: true, B: false}, mesmo quando typographer: true continua funcional, devido à complexidade percebida.

Estou lendo nas entrelinhas e ele é um russo escrevendo em inglês. Mas tenho a sensação de que ele vê o markdown-it como algo já consolidado.

Com toda a gratidão, talvez valha a pena fazer um fork da implementação, reescrevê-la como Módulos ES e remover toda a funcionalidade do tipo plugin que está atualmente embutida, tanto a ligação de links quanto as substituições, incluindo as substituições de pontuação do tipógrafo.

3 curtidas

O mantenedor não tem interesse em pontos sobre código duplicado em bundles sem números. Também não se interessa por mudanças que não quebrem a API, a menos que sejam ‘exigidas por 100% dos usuários’ ou que bloqueiem implementações de plugins. Isso cria um certo impasse, já que eles estão lançando dois submódulos muito voltados para plugins, para linkificação e pontuação inteligente, que, segundo essa filosofia, deveriam estar em seus próprios pequenos pacotes npm. Isso acontece.

Para contextualizar, houve lançamentos significativos do markdown-it no passado recente. Destaque para uma melhoria de desempenho feita por Alex Kocharin em novembro do ano passado.

Para corrigir (c), lidar com (p) e fazer o que quisermos com setas e afins, a melhor opção é provavelmente propor um patch que remova os submódulos de linkificação e pontuação inteligente do núcleo e os carregue como plugins no Discourse. Use uma GitHub Action ou uma tarefa agendada (cron job) para monitorar a branch master do markdown-it e tentar um rebasing automático. Se o mantenedor continuar tão conservador em relação a mudanças, o patch deve se aplicar corretamente por um bom tempo. A menos que eles deem um grande salto, como reescrever o projeto usando ES Modules em vez de CommonJS.

6 curtidas

Discutimos isso internamente e decidimos que faremos um hard fork do typographer.

Basicamente, desabilitaremos o typographer no markdown.it e implementaremos uma cópia no Discourse. O markdown.it é extremamente extensível; isso é basicamente “copiar e colar”.

Assim que a cópia for concluída, poderemos adicionar testes, personalizar e alterar algumas das regras.

9 curtidas

Ei, desculpe retomar essa discussão. Como estou procurando uma maneira de desabilitar ... -> …, gostaria de saber se essa funcionalidade evoluiu de alguma forma e se no futuro poderei habilitar ou desabilitar regras individuais.

Obrigado!

2 curtidas

É uma configuração do site, basta desativar o tipógrafo

2 curtidas

Bom, eu já tentei isso, mas aparentemente não está funcionando. Não importa se eu ativo ou desativo o tipógrafo, as substituições sempre são feitas (e, aliás, o (c) não parece funcionar).

2 curtidas

Você precisa desabilitar e depois reconstruir o HTML nas suas postagens desejadas.

5 curtidas

Isso agora está muito completo :confetti_ball:

2 curtidas