Ele é semelhante ao glow, mas os hiperlinks aparecem mais compactos (porque a visualização no glow fica muito confusa quando tem muitos deste seguidos) e suporta funções algumas funções que estão fora do CommonMark, como as notas e notas de rodapé do GitHub, e algumas de html como as seções colapsáveis.
Não me preocupei em deixar tudo colorido porque acho que a visualização dos elementos já tá boa o suficiente.
Screenshot
O código está em:
deem uma olhada lá, é basicamente um monte de regex, parece fácil mas eu quebrei muito a cabeça em… e ainda não está pronto, mas é usável.
Meu script MarCLIdown agora reconhece e formata algumas (“ ”, “ ”, “ ”, “ ”) entidades HTML. As outras entidades são apenas ocultadas da saída do comando.
Para efeito de comparação, abaixo, o MarCLIdown também tem uma demonstração de como o glow lida com as mesmas ocorrências:
Infelizmente o “thin space” (espaço fino) tem a mesma largura de um espaço normal (porque aparentemente mesmo insirindo um espaço fino os terminais continuam mostrando com a largura padrão), e o “espaço sem quebra de linha” ainda é apenas um caractere de espaço comum (vou tentar fazer isso quando começar a trabalhar com o tratamento das quebras de linha automáticas).
Não, funciona mais como um visualizador, você escreve um arquivo.md e ele renderizar (como se fosse um Okular da vida), o ponto chave é que ele faz isso no terminal
Verdade man, mesmo que provavelmente o falante de cada idioma já tenha uma maneira mais pratica de digitar seus símbolos comuns, por exemplo o teclado espanhol já tem “¡”, “¿” e “ñ”, embora isso ainda tenha utilidade quando um falante de outra idioma precise usar esses símbolos (mesmo que a pessoa provavelmente vai pensar primeiro em procurar em algum mapa de caracteres, ou se tiver usando o teclado virtual isso já vai estar disponível), mas acho que é um uso justo, por hora acho que vou incluir os caracteres matemáticos e os símbolos das moedas.
O problema é que eu não sei o real ‘peso’ de cada regex que eu incluo ao script, tipo 100 regexes buscando ocorrências que não existem no documento em questão vão deixar o script perceptivelmente mais lento? (eu coloco um teste que só os executa caso tenha pelo menos uma ocorrência no texto) Vou estudar mais sobre isso e fazer uns benchmarks para decidir o que fazer.
Seria bom ter um suporte amplo à qualquer cenário, assim como os renderizadores no navegador fazem, mas qualquer coisa eu separo esse tratamento de entidades em um script separado e durante a instalação via cURL ele pergunta se tu quer ou não isso, e também precisaria de um pacote a mais nos repositório (provavelmente vou subir só no AUR mesmo).
Mas vou deixar pra depois porque tem coisas mais importantes, vou alterar a exibição dos títulos/cabeçalhos, tô com uma ideia legal pra melhorar a visualização deles mesmo mantendo a saída monocromática. Depois refazer o tratamento de flags porque tá uma porcaria e quando eu ativo alguma opção via alias não tem como rodar o comando sem essa opção, porque não tem nenhuma flag que force o desuso dela…
Ele imprime um arquivo no terminal, formatando-o de acordo com a sintaxe do markdown, também tento dar suporte à alguns elementos html que sejam comuns se encontrar dentro de arquivos markdown (tipo seções colapsáveis[recolhíveis], e futuramente textos centralizados ou alinhados à direita).
Depois de instalação é só rodar tipo: marclidown ~/Documentos/notas.md ~/Downloads/outro\ arquivo.md
Ou então se seu arquivo usa a sintaxe markdown mas não tem a extensão .md, dá pra pular a verificação com: marclidown --force ~/Downloads/todo.txt
E claro que também da pra passar o caminho de mais de um arquivo como em qualquer programa unix, tipo: marclidown ~/Documentos/*.md para imprimir todos os arquivos .md na pasta Documentos da sua home.
Eu quero que ele seja bem portátil, podendo rodar em qualquer Linux, BSD e Mac mas isso ainda não acontece…
Se tu quiser só testar recomendo instalá-lo via cURL (sh <(curl -L https://codeberg.org/NihaAlGhul/MarCLIdown/raw/curl/install) e se quiser alterar o código é clonando o repositório (linkado na primeira postagem).
Essas marcas (o HTML Entity) não serve para digitar o símbolo, serve para garantir que diferentes codificações em sistemas mais esotéricos e primitivos em relação a codificações (Windows) exibam corretamente o símbolo, geralmente eles são desnecessários porque atualmente se convenciou a usar UTF-8 nas páginas mas existe uma possibilidade remota de não ser, o problema de não interpretar é que vai ficar assim na exibição
@NihaAlGhul Seu programa não funciona, o SH fica reclamando de problema na linha 100, e se trocado pelo bash fica reclamando de que esta faltando o EOF.
Tentei encontrar onde vc esqueceu de colocar o EOF, mas não tive sucesso, eu tentei com o programa de inspeção de codigo de script shell e ele tmb não encontra o problema.
Caso queira usar o programa de inspeção de codigo de script shell para te ajudar eu uso o progrema shellcheck
Ele tmb tem a versão online que vc usa pelo navegador se preferir: https://www.shellcheck.net/
O shellcheck é GPLv3.
A e quem interpreta o SH no Ubuntu é o interpretador dash, e ele esta na versão:
A o meu Kubuntu é 22.04, vê ai se da para corrigir ou me diz como eu resolvo o problema pq aqui não funciona.
A mais uma coisa, eu não executei o make, eu baixei o arquivo de shell e executei na minha pasta de usuário.
Então @Natanael.755 aqui se eu trocar para Bash tmb não funciona, será que é a versão do meu Bash? ele esta no 5.1.16
Ai esta funcionando direitinho sem erro?
O projeto é muito interessante, mas por ser escrito em shell tem diversas disvantagens sob o glow(vou comparar pois no seu proprio repositorio fez diversas comparações).
Glow é um programa Compilado, escrito em GO, e por isso é multiplataforma e multishell também. Glow roda no windows, linux, macos…
Eu por exemplo não conseguiria executar ele por usar FISH como shell padrão.
Em ambientes ZSH, também devem existir incompatibilidades, ou, por exemplo, no alpine Linux, que usa Dash.
Dito isso, é um projeto muito respeitável e bem impressionante trabalhar com shell scrpt puro não é muito fácil não, parabéns pela iniciativa e por ajudar o ecossistema open source!
Não sabia dessa, mas também tem outro uso bacana [como um escape de syntax, pois esses caracteres não servem como indicadores de marcação] que encontrei na especificação do GFM:
6.2 Entity and numeric character references
Valid HTML entity references and numeric character references can be used in place of the corresponding Unicode character, with the following exceptions:
Entity and character references are not recognized in code blocks and code spans.
Entity and character references cannot stand in place of special characters that define structural elements in CommonMark. For example, although * can be used in place of a literal * character, * cannot replace * in emphasis delimiters, bullet list markers, or thematic breaks.
Conforming CommonMark parsers need not store information about whether a particular character was represented in the source using a Unicode character or an entity reference.
Burrice minha mesmo mano, fazer a shebang apontar pro shell padrão ao invés do bash foi uma tentativa de torná-lo mais portátil e com menos dependencias instaláveis, por exemplo no no MacOS ele rodaria pelo Zsh (o que provavelmente é melhor do que apontar para a versão antiga do bash que tem nesse sistema) que tem uma boa compatibilidade com o que foi feito pro Bash, mas como tu disse isso é um problema em sistemas em que o shell padrão tem muitas imcompatibilidades com o bash, como os BSD’s, Debian (e derivados) e Alpine, que tem usam shells baseados nos de algum BSD (faz tempo que lí sobre isso).
Então acho que o mais lógico é fazer a shebang apontar pro bash mesmo, e marca-lo como dependencia até que eu possa examinar todos os shells dos sistemas populares e resolver os conflitos durante a instalação/subir nos repositórios de cada sistema já com as alterações necessárias.
Também calhou que em todos os ambientes em que eu testei, env sh apontava para o bash…
Edit: outra opção também é colocar no na seção de # instalação do readme, comandos com tratamentos diferentes, para cada caso conhecido como tu mostrou:
## on macos
bash <(curl -L https://codeberg.org/NihaAlGhul/MarCLIdown/raw/curl/install | sed 's|env sh|env zsh|g')
\# considerando que o zsh realmente seja capaz de executálo sem erros
## on linux
bash <(curl -L https://codeberg.org/NihaAlGhul/MarCLIdown/raw/curl/install | sed 's|env sh|env bash|g')
\# tendo em vista que (tirando o alpine) acho que qualquer distro popular que use outro shell por padrão ainda mantém um bash moderno instalado
## on freebsd
pkg install bash
bash <(curl -L https://codeberg.org/NihaAlGhul/MarCLIdown/raw/curl/install | sed 's|env sh|env bash|g')
\#tendo em vista que o sistema não tem nenhum shell muito compatível com o bash, e ele não vem instalado por padrão
Depois deve ser só automatizar tudo isso no script de instalação mesmo, ou até mesmo no makefile…
