Microsoft considerada prejudicial
Origens do Markdown
O ponto de Especificação de sintaxe de Markdown de John Gruber era que o seu “Desconto” foi concebido para ser fácil de trabalhar com; não apenas do ponto de vista da autoria, mas também da perspectiva de um implementador. , MathML, e HTML5 não são isso.
GitHub Markdown com Sabor (GFM)
GFM permaneceu fiel aos objetivos de design dessa especificação até Microsoft bastardizou o cifrão isolado para convertê-lo condicionalmente em um token1 por causa de alguns lixo institucional clausurado, antiquado, feio e lento chamado MathJax que não tinha nada a ver com Markdown, e o fato de que esses idiotas não querem promover performant, bonito, utf8Compatível sem suborno da Khan Academy.
Abrace e Amplie o Redux
É claro que isso foi totalmente intencional, porque premiado, equipes de engenharia de classe mundial tinha se estabelecido em com limites de token de dólar duplo para matemática em linha, e blocos matemáticos vedados ou pares de parágrafos circundantes somente de dois dólares para bloco processando em 2015 — quatro anos antes da publicação da especificação GFM.
O ponto aqui é que um delimitador de 2 caracteres que raramente ocorre em prosa típica é o ideal normal para situações como esta. Tinha Microsoft preso apenas apoiando $` … `$ Eu não estaria escrevendo este artigo em 2026, porque essa escolha atende às condições ideais normais para a introdução fiel de expressões matemáticas em linha em uma especificação Markdown. Essa escolha também é propícia à síndrome do túnel do carpo para tipistas profissionais de matemática, então há outra coisa a considerar além da singularidade do token de fronteira.
Se eu tivesse que adivinhar seus motivos para considerar que a sintaxe proposta do artigo do blog é insuficiente para suas necessidades atuais, eu suspeito que eles eram mais sobre ganância e controle de mercado e “insatisfação do cliente” Muito bom F/OSS.
Ou apenas Preguiça, impaciência e HubrisMas isso não é conspiratório o suficiente para este artigo. AMMV.
WorldWide Raio de Explosão
É agora um desastre ambíguo de defeitos regex de engenharia cada vez que um autor / implementador tem que adivinhar o que o analisador deve fazer com sequências de cifrões isolados ocorrendo dentro de um único parágrafo de prosa de markdown. Por exemplo, considere uma situação em que Francês Matemáticos financeiros canadenses discutem dois preços em duas moedas diferentes, dizem EUA $1.50 e 2,00$ CA (admitidamente inventado, mas ilustra a complexidade). Como você escreveria um i18n em conformidade Analisador GFM que entende que o material entre os cifrões aqui é não deve ser processado como inline , embora seja sintaticamente válido e está em conformidade com isso especificação ingênua?
Que tal um par de variáveis Ruby/Perl em uma assinatura de função como foo($v,$w)? O mesmo problema com a ingenuidade. Ter Claude2 analisar tudo?
Boa sorte com isso se você estiver fazendo uma conversão GFM em massa de formatos de documentos legados internacionais para uma plataforma não-GitHub. Não só será incrivelmente lento e caro, mas só “trabalho” quando renderizado no Visual Studio, se mesmo funciona.
Uma coisa é dizer que você não vai escrever coisas hoje que confundem o analisador agora; é bem diferente dizer que as coisas escritas no passado também não confundirão o analisador. Não hoje e não versões do parser futuro.
Ao contrário dos padrões emergentes do JCP, nunca haverá um conjunto de testes de certificação de conformidade para essa bagunça, porque é um evolução situação em o chão em GitHub2,3:
GitHub não divulgou publicamente seu atual analisador de markdown de código aberto. No entanto, sabe-se que o GitHub usa uma implementação personalizada de Markdown para sua plataforma, que é baseada na especificação GitHub Flavored Markdown (GFM). Esta implementação inclui suporte para várias extensões e recursos que aprimoram a sintaxe de Markdown usada pelo GitHub.
Novamente, desvio intencional dos objetivos de Gruber.
Mais repugnantemente, o abraço e extensão do império do mal tem um exército de escravos do trabalho livre F / OSS para servir como polícia de pensamento sicofântico sobre seus esforços para roubar o trabalho dos outros para seus próprios ganhos de mercado através da IA3. Basta verificar as respostas para o post HackerNews sinalizado desta página na seção Links abaixo para conhecer alguns deles.
Fuck Microsoft
Resumindo, a GFM não é mais uma especificação da indústria internacional, mas um formato de fornecedor proprietário feio-americano não é diferente do Lixo Wikimedia Eles copiaram.
Orion não usa e nunca usará parsers GFM mais recentes que fingem rastrear esse mal-estar sujo.
Em vez disso, contamos com um fork interno de @markedjs/marked e continuaremos a fazê-lo no futuro previsível.
Rodapés
Não é um “extensão” da especificação quando o autor da especificação a obriga a todos que usam seus produtos. É A NOVA ESPÉCIE DE FATO.
Para os nitwits que ainda acreditam que GitHub está usando F/OSS para analisar markdown: Eu encorajo você a clicar no link de origem GitHub para este artigo no topo da página, copiar e colar os dois primeiros parágrafos da seção WorldWide Raio de Explosão em um editor de markdown GitHub, remova os backticks em torno dos cifrões e testemunhe em primeira mão que ele renderiza os casos de amostra corretamente, ao contrário da porcaria F/OSS Rust que afirma usar. Também pode ser conveniente comparar a estética do renderizador MathJax com a do que usamos neste site, para esclarecer qualquer confusão sobre as discrepâncias qualitativas entre os dois produtos, muito menos os quantitativos como eles se relacionam com a velocidade de renderização.
A prosa citada foi a resposta original da IA do bing nas últimas 24 horas, até que eu adicionei os links de fundo adicionais a este artigo, a partir do qual “aprendido” Como dizer algo menos idiota em resposta à consulta “o que é o analisador de markdown de código aberto atual do github”. Esta é a IA que está tomando nossos empregos, pessoal.
