Tufte-css: Remarcação para isso?

O Pandoc oferece modelos para construir, portanto, a criação de um modelo Tufte pandoc deve ser simples.

@langford acabou que já existe um modelo Tufte para Pandoc, veja meu comentário aqui para obter detalhes sobre a conversão de Markdown / Multi-Markdown em estilos Tufte: https://github.com/daveliepmann/tufte-css/issues/30#issuecomment - 128718117

@ xHN35RQ depois de examinar um pouco, os modelos pandoc parecem ser o caminho errado para essa funcionalidade: um modelo recebe uma string $body$ e espera apenas colocar texto antes e depois, e não parece destina-se a realmente manipular o texto gerado a partir da marcação. Você usaria escritores personalizados pandoc que você pode escrever (aleluia) em Lua. Eu escrevi um escritor personalizado barebones que apenas implementa notas secundárias e adiciona a tag article : veja a essência . Espero expandir isso à medida que continuo escrevendo tufte-css para incluir todos os recursos fornecidos - de preferência, sem ter que modificar nada sobre o pandoc markdown ou seus leitores.

(Para ser mais completo, posso mencionar os filtros pandoc como algo que pode eventualmente ser necessário para produzir totalmente HTML habilitado para tufte-css a partir da marcação pandoc, mas provavelmente apenas para coisas muito complicadas. Os filtros manipulam o AST, antes que um AST seja fornecido a um redator personalizado . O lugar certo para fazer notas secundárias no estilo tufte-css era no escritor personalizado, não como um filtro.)

@fasiha bom trabalho. Você fez um começo promissor aqui. : +1:

Não acho que exista um equivalente prontamente disponível para tufte-css _sections_ no Markdown, ou seja, um agrupamento de parágrafos e cabeçalhos. Mas acho que gosto da ideia de seções, acho que ter um nível extra de organização de documentos será útil no futuro.

Alguma sugestão da comunidade sobre como indicar seções no Markdown?

@fasiha Que tal um filtro que leva os elementos do título e todos os elementos do parágrafo até o próximo elemento do título? Em seguida, envolva-os em <section> (ou algumas tags personalizadas <div> ) e aplique o css desejado a isso?

Obrigado por pesar em @vyp. Da minha leitura da página inicial do tufte-css, section pode capturar mais de um título, ou parágrafos sem título. Ou seja, não é apenas um contêiner de título e conteúdo. No meu documento, estou apenas incorporando <section> como HTML bruto no Markdown por enquanto - para isso, acho que posso aceitar HTML bruto.

@fasiha Ah, desculpe, você está correto. Como uma seção é definida como um "agrupamento lógico de texto e títulos", é impossível determinar o que exatamente é uma seção em um documento sem entrada humana (ou seja, marcamos as seções como informações semânticas, assim como marcamos com ênfase com asteriscos ou sublinhados). E sim, não estou ciente de qualquer sintaxe pré-existente para essas "seções" em qualquer tipo de marcação, então boa pegada.

Usar tags <section> brutas é a melhor coisa possível a se fazer neste caso (além de definir sua própria sintaxe do tipo markdown para ela e escrever um analisador para ela).

Outra maneira seria usar o fato de que tufte diz que usa h2 para "cabeçalhos de seção", então talvez uma "seção" possa ser definida como uma tag h2 e tudo até a próxima tag h2 e assim por diante. Mas não tenho certeza se é isso que o autor de tufte pretendia.

Os elementos H2 não são fontes confiáveis ​​de demarcação de seção. Por exemplo, alguns documentos usam extensões de "pensamento novo". Tenho certeza de que outras variações surgirão na natureza.

Em 8 de agosto de 2015, às 23:49, vyp [email protected] escreveu:

@fasiha Ah, desculpe, você está correto. Como uma seção é definida como um "agrupamento lógico de texto e títulos", é impossível determinar o que exatamente é uma seção em um documento sem entrada humana (ou seja, marcamos as seções como informações semânticas, assim como marcamos com ênfase com asteriscos ou sublinhados). E sim, não estou ciente de qualquer sintaxe pré-existente para essas "seções" em qualquer tipo de marcação, então boa pegada.

Usando cru

tags é a melhor coisa possível a fazer neste caso (além de definir sua própria sintaxe do tipo markdown para ela e escrever um analisador para ela).

Outra maneira seria usar o fato de que tufte diz que usa h2 para "cabeçalhos de seção", então talvez uma "seção" possa ser definida como uma tag h2 e tudo até a próxima tag h2 e assim por diante. Mas não tenho certeza se é isso que o autor de tufte pretendia.

-
Responda a este e-mail diretamente ou visualize-o no GitHub.

Eu acho que se alguém quiser evitar o uso de tags <section> em seu markdown, alguma sintaxe semelhante a <hr> pode não ser difícil de implementar. A sintaxe para <hr> 's é basicamente "três ou mais hifens, asteriscos ou sublinhados em uma linha por si só". Então, por exemplo, você pode definir arbitrariamente uma demarcação de "seção" como "três ou mais sinais de igual" (ou o que você preferir) e, em seguida, usar um filtro pandoc para envolver tudo entre cada um desses parágrafos com apenas sinais de igual.

Eu apenas escolhi "uma linha de sinais de igual" porque acho que é assim que dividir as seções com texto simples _seria_? E porque a marcação pandoc irá analisar isso como apenas um parágrafo, o que significa que seu filtro pode apenas verificar cada parágrafo se ele tem apenas sinais de igual ou não, e se ele é feito apenas de sinal de igual, suponha que isso seja parte de uma demarcação de seção.

Olá a todos (e obrigado a @daveliepmann por me apontar para este tópico). Você pode se interessar pelo meu pacote glasseye , no qual usei o Tufte.css (então, obrigado a todos por isso) e no qual pretendo integrar o markdown, o d3 e o layout Tufte. No momento, é um protótipo com muitos cortes de cantos. Quando eu tiver um momento, gostaria de limpar o código e racionalizar um pouco o design (nesse ponto, estarei analisando seus comentários sobre o css). Mas eu queria ver se valia a pena fazer primeiro e acho que vale. De qualquer forma, adoraria qualquer feedback.

ReStructuredText seria mais acessível do que Markdown para o tipo de anotações que são necessárias aqui?

@coppeliaMLA Obrigado por mencionar glasseye, é um trabalho incrível.

@rbcarson Eu não sou OP, mas se a pergunta é direcionada a todos aqui e você quer minha opinião, eu pessoalmente não estou familiarizado com o texto reestruturado, então não posso dizer. Mas você pode estar certo, a sintaxe básica de markdown criada por Gruber, Swartz e companhia foi inspirada em como as pessoas escreviam (texto simples) e-mails 'naquela época'. Portanto, só começou tão complexo (ou tão 'capaz') quanto uma mensagem de e-mail comum poderia ser, não um artigo de pesquisa ou alguma outra forma de escrita que usa muitas notas secundárias ou segue ou faz sentido com o estilo de Tufte.

Com o passar dos anos, há um limite para outro tipo de sintaxe que você pode colocar em "markdown" porque o ponto principal disso é que deve ser legível na forma de texto simples. Como você transmite notas secundárias visualmente em texto simples? No entanto, eu sinto que o markdown estendido de pandoc fez um trabalho muito bom a esse respeito.

Então eu acho que o texto reestruturado tem algo chamado de diretivas ou algo assim, que permite que você construa a sintaxe (ou algo assim?) Para um tipo específico de dados? Se for esse o caso, sim, eu acho que o texto reestruturado é provavelmente mais adequado aqui. Mas, como eu disse, não tenho muita experiência com isso, então não posso te ajudar mais.

reestruturadoText seria inútil para meus propósitos, que são projetos já documentados em markdown

Em 17 de agosto de 2015, às 4h24, vyp [email protected] escreveu:

@coppeliaMLA Obrigado por mencionar glasseye, é um trabalho incrível.

@rbcarson Eu não sou OP, mas se a pergunta é direcionada a todos aqui e você quer minha opinião, eu pessoalmente não estou familiarizado com o texto reestruturado, então não posso dizer. Mas você pode estar certo, a sintaxe básica de markdown criada por Gruber, Swartz e companhia foi inspirada em como as pessoas escreviam (texto simples) e-mails 'naquela época'. Portanto, só começou tão complexo (ou tão 'capaz') quanto uma mensagem de e-mail comum poderia ser, não um artigo de pesquisa ou alguma outra forma de escrita que usa muitas notas secundárias ou segue ou faz sentido com o estilo de Tufte.

Com o passar dos anos, há um limite para outro tipo de sintaxe que você pode colocar em "markdown" porque o ponto principal disso é que deve ser legível na forma de texto simples. Como você transmite notas secundárias visualmente em texto simples? No entanto, eu sinto que o markdown estendido de pandoc fez um trabalho muito bom a esse respeito.

Então eu acho que o texto reestruturado tem algo chamado de diretivas ou algo assim, que permite que você construa a sintaxe (ou algo assim?) Para um tipo específico de dados? Se for esse o caso, sim, eu acho que o texto reestruturado é provavelmente mais adequado aqui. Mas, como eu disse, não tenho muita experiência com isso, então não posso te ajudar mais.

-
Responda a este e-mail diretamente ou visualize-o no GitHub.

@coppeliaMLA muito interessante !: use o pandoc para gerar HTML com tags especiais e, em um segundo estágio, use outro programa para expandir as tags especiais para Javascript e HTML. Minha abordagem tem sido fazer um escritor personalizado do Pandoc que consome as tags especiais, efetivamente fazendo glasseye.py em Lua, usando o Pandoc AST em vez da análise BeautifulSoup, mas parece que o glasseye está basicamente funcionando bem. Vou tentar analisar meus documentos e informá-lo sobre seu repositório sobre quaisquer problemas. Coisas que são difíceis de fazer em um escritor Pandoc podem ser mais fáceis de fazer pós-processamento e vice-versa, mas a única maneira de descobrir é escrever um monte de documentos :)

@fasiha obrigado. Seu caminho parece mais eficiente e acho que possivelmente vou seguir nessa direção no final. Eu optei pelo python, pois me permitiu criar um protótipo rápido. Mas, como você diz, experimentar em muitos documentos aperfeiçoará o melhor método. Estou planejando usá-lo para o máximo possível do meu trabalho diário, para ver aonde ele me leva. Seria ótimo se você pudesse tentar. Adoro ouvir como vai!

Veja # 31 e também # 58

Pelo que vale a pena: acabei de juntar tufte-pandoc-css para resolver o problema de escrever notas laterais no Markdown. É apenas uma demonstração de como usar um filtro Pandoc personalizado que escrevi chamado pandoc-sidenote .

Para vê-lo em ação:

• Uma reimplementação tufte- css / index.html no Markdown com sabor de Pandoc
• Uma demonstração de alguns outros recursos do Pandoc , como blocos de código destacados pela sintaxe.

@jez Cool! Vou ver se consigo encontrar um projeto para dar uma olhada nisso.

Acabei de encontrar este tópico através do Google

Vocês podem querer dar uma olhada no xmark : que converte markdown em Tufte-CSS via XSLT.

@vieiro uau, isso é legal. Bom trabalho 👍🏻