Latex3: Documentar códigos de cat para o tipo de argumento "literal" do xparse, documentar como reproduzir \ verb

O que você está vendo é a ligadura -- na fonte da máquina de escrever. Se você escrever \texttt{--} também verá um único traço, mas se copiar do PDF, verá que é realmente um traço. Você pode verificar isso alimentando o argumento capturado para \showtokens ou usando \@noligs (o LaTeX usa isso em \verb para ter -- print -- ):

\documentclass{article}
\usepackage[T1]{fontenc}
\usepackage{xparse}
\makeatletter
% \NewDocumentCommand {\myverb} { v } { \showtokens{#1} }
\NewDocumentCommand {\myverb} { v } {#1}
\begin{document}
\makeatletter
\ttfamily \<strong i="13">@noligs</strong>
-- and \verb|--all|

- and \myverb{-all}

-- and \myverb{--all}

--- and \myverb{---all}
\end{document}

mas v in xparse deve ser literal (não é?) e em LaTeX isso significa máquina de escrever com ligaduras suprimidas, então v deveria fazer isso também em minha opinião.

Ele apenas pega literalmente (literalmente aqui sendo algum equivalente a \let\do\<strong i="5">@makeother</strong> \dospecials ). \@noligs pode ser adicionado na configuração do catcode para escanear o argumento. Por outro lado, isso inseriria tokens ativos onde (teoricamente) há apenas catcode-other tokens, então, caso o argumento seja usado para algo diferente de composição, pode ser problemático.

Talvez alguma forma de permitir que o comando adicione suas próprias configurações de catcode, como:

\NewDocumentCommand {\myverb} { v{\@noligs} } {#1}

@FrankMittelbach Concordo com PhelypeOleinik que “literalmente” significa “pegue o que o usuário escreveu literalmente”. A ligadura <hyphen hyphen> to <endash> é mais um “recurso de fonte” do que um “bug para agarrar argumentos”. Além disso, \ttfamily não significa “fonte monoespaçada = sem ligadura de qualquer espécie”. Alguns tipos de fontes monoespaçadas podem ser usados ​​como tipo de corpo (não apenas código), portanto, as ligaduras de hífen não devem ser suprimidas nesses casos.

Mas \NewDocumentCommand {\myverb} { v } {#1}\myverb{--all} deveria se comportar como \verb|--all| ?

@dbitouze - não realmente. \ verb tem duas partes - captura de argumento e formatação. A configuração “v” em \ NewDocumentCommand só faz o primeiro.

@Phelype - a menos que esteja faltando alguma coisa, sua sugestão não faz mais do que isso ?:

\NewDocumentCommand {\myverb} { v } { {\<strong i="9">@noligs</strong> #1} }

Nesse caso, não acho que seja necessário. Então, de volta ao @dbitouze , a maneira de replicar \ verb é algo como:

\ makeatletter
\ NewDocumentCommand {\ myverb} {v} {{\ @noligs \ ttfamily # 1}}
\ makeatother

Na quinta-feira, 25 de junho de 2020 às 08:22, Denis Bitouzé [email protected]
escreveu:

Mas não é \ NewDocumentCommand {\ myverb} {v} {# 1} \ myverb {- all} suposto
se comportar como \ verb | --all |?

-

Não exatamente, já que v trata apenas de analisar o argumento, e isso é lido
literalmente, o verbo também compõe o conteúdo em uma fonte monoespaçada não padrão
configuração que suprime ligaduras.
então, ao invés de apenas #1 para escrever o argumento na fonte atual, você
necessário fazer

\verbatim@font\<strong i="19">@noligs</strong>
\language\l<strong i="20">@nohyphenation</strong>

exceto que \ @noligs requer
\ defverbatim @ nolig @ list {\ do` \ do \ <\ do> \ do \, \ do \ '\ do-}
para ser ativo, portanto, poderíamos considerar fazer v definir aqueles como ativos. ou
fornecendo um invólucro em torno de scantokens que faz com que \ @noligs funcione
aqui

Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/latex3/latex3/issues/756#issuecomment-649302149 ou
Cancelar subscrição
https://github.com/notifications/unsubscribe-auth/AAJVYAVLBB4ABB3DD5TETRDRYL3MPANCNFSM4OHMH74A
.

@dbitouze não, a semelhança está apenas na forma como o argumento pode ser delimitado: você pode usar \ myverb! abc !. O resultado é documentado como

que resultará no argumento agarrado consistindo de tokens dos códigos de categoria 12 (“outro”) e 13 (“ativo”), exceto espaços, que recebem o código de categoria 10 (“espaço”).

O analisador de argumentos apenas lê um argumento, ele não o edita. E não faria sentido adicionar comandos de fonte ou outros comandos a ele ou mesmo pré-processá-lo para aplicar \@noligs por padrão: Existem outras maneiras de suprimir ligaduras. Com luatex, seria possível aplicar Ligatures=Resetall e com pdflatex seria possível usar \pdfnoligatures com uma fonte ligeiramente diferente:

~~~~
\ RequirePackage {fix-cm}
\ documentclass {artigo}
\ usepackage [T1] {fontenc}
\ usepackage {xfp, xparse}

\ makeatletter
\ NewDocumentCommand {\ myverb} {v} {{\ fontsize {\ fpeval {\ f@size+0.0001 }} {\ normalbaselineskip} \ selectfont \ pdfnoligatures \ font # 1}}
\ makeatother

\ begin {document}
--tudo

verbo | --todos |

\ myverb {-todos}

\ myverb {- todos}

\ myverb {--- all}

\ footnotesize
--todos \ myverb {- todos}

\ ttfamily
--tudo

verbo | --todos |

\ myverb {-todos}

\ myverb {- todos}

\ myverb {--- all}

\ footnotesize
--todos \ myverb {- todos}

\ end {document}
~~~~

@phelype - a menos que esteja faltando alguma coisa, sua sugestão não faz mais do que isso ?:
\ NewDocumentCommand {\ myverb} {v} {{\ @noligs # 1}}

@wspr Tipo de, mas não: \@noligs muda o catcode de - (e vários outros) para 13 e, em seguida, define-o como \def-{\leavevmode\kern\z@\char`-} : sendo uma mudança de catcode, tem que ser feito antes que o argumento seja capturado (a menos que estejamos considerando \scantokens ), portanto, minha sugestão para permitir um argumento de “configuração de catcode” para v (embora tivesse que ser opcional: \NewDocumentCommand {\myverb} { v[\@noligs] } {#1} ).

Obrigado @phelype - já faz um tempo desde que olhei dentro dessa macro :)
Nesse caso, gosto da ideia do argumento de configuração ... mesmo que neste caso outras abordagens também possam funcionar para desativar as ligaduras.

Não temos dados opcionais na especificação do argumento, então seria necessária uma nova letra ( w ?)

Ou uma alteração importante para v -tipo

Eu prefiro votar em V (combinando que temos o e O e d e D) do que considerar uma alteração significativa.

Não temos dados opcionais na especificação do argumento, então seria necessária uma nova letra ( w ?)

Não podemos adicionar um?

Ou talvez, uma vez que temos o e O{} , parece natural ter v e V{} . Claro que o argumento significaria coisas diferentes ...

Imho, se os catcodes devem ser personalizáveis ​​para o tipo-v, faria sentido usar o código cctab, e não algum comando arbitrário como \@noligs . Então a leitura do comando apenas definiria os catcodes e as definições dos caracteres ativos deveriam ser feitas no corpo da macro.

@ u-fischer Então é melhor eu conseguir aquele PR de l3cctab em ...

Atualmente, não tenho ideia de como l3cctab funciona e como isso pode ser útil para o problema atual, mas estou realmente interessado :)

Meu ponto é que semanticamente v é 'literalmente' enquanto o que é necessário aqui não é. Mais importante, você deve se preocupar se os caracteres de delimitação são alterados pela tabela catcode ou qualquer outra coisa. Além disso, temos sido consistentes com as letras maiúsculas -> alguma variante opcional-arg de uma minúscula. Portanto, eu diria que algo como c{<table>} (= 'catcode') estaria certo.

Vou ordenar o material de cctab hoje ou amanhã, se puder, para que possamos discutir.

@dbitouze Uma tabela catcode é uma forma de ter um conjunto 'fixo' de catcode para todos os chars (*). Isso significa que você obtém uma interface de um token para as alterações, então ' \c_document_cctab para catcodes normais, \c_initex_cctab para IniTeX, etc. A ideia é que isso é muito mais claro e confiável do que um- por-um configuração.

• No XeTeX, não temos a primitiva necessária, então só posso cobrir os caracteres de 0 a 255 com desempenho razoável.

@josephwright (fora do tópico) Parece-me que você queria adicionar uma nota de rodapé, mas Markdown não sabia disso.

Suprimir um conjunto conhecido de ligaduras durante a saída também pode ser feito usando \tl_replace_all:Nnn e substituindo o caractere problemático por algo que não formará a ligadura.

@Skillmon Bom argumento: pode-se pegar o material literal e substituir os tokens. Como tudo é estritamente literal, essa é provavelmente uma abordagem mais fácil do que se preocupar com a configuração do catcode.

Independentemente do resultado desta discussão, será útil documentar em
xparse.pdf como reproduzir o comportamento do verbo usando \ NewDocumentCommand.

@josephwright dependendo do número de tokens a serem substituídos, o desempenho será muito pior com a abordagem \tl_replace_all:Nnn .

Além disso, como você saberá quais caracteres (em uma fonte muito grande) precisam ser substituídos?

Além disso: o que a composição 'literalmente com uma fonte monoespaçada' significa para muitos scripts (não europeus)?

@ car222222 em uma fonte muito grande você obteve as características da fonte como a única maneira razoável de suprimir todas elas, o LaTeX não pode saber sobre todas as ligaduras possíveis em uma fonte. Mas pelo menos os caracteres com suporte para LaTeX2e poderiam ser cobertos facilmente (é apenas \tl_map_function:NN e \tl_replace_all:Nnn ).

Além disso: AFAIK, existem símbolos com espaçamento duplo em algumas fontes monoespaçadas para alguns scripts não europeus.

Eu sugeriria apenas envolver todos os caracteres em um hbox. Parece funcionar
razoavelmente bem, mas não testei extensivamente.

\ RequirePackage {xparse}
\ ExplSyntaxOn
\ NewDocumentCommand {\ myverb} {v} {\ texttt {\ str_map_ function: nN {# 1} \ hbox: n }}
\ ExplSyntaxOff
\ documentclass {artigo}
\ usepackage [T1] {fontenc}
\ begin {document}
verbo | a - b --- c `` <'' |

\ myverb | a - b --- c `` <'' |
\ end {document}

Eu sugeriria apenas envolver todos os caracteres em um hbox. Parece funcionar razoavelmente bem, mas não testei extensivamente.

Experimente com |a--bgrüße ---c ``<''|

Ok, segunda tentativa (o v arg mantém os caracteres ativos como estão): insira \kern 0pt\relax antes de todos os caracteres não ativos.

\RequirePackage{xparse}
\ExplSyntaxOn
\tl_new:N \l__myverb_tl
\cs_new:Npn \__myverb:n #1
  {
    \token_if_active:NF #1 { \kern 0pt\relax }
    \exp_not:n {#1}
  }
\NewDocumentCommand { \myverb } { v }
  {
    \tl_set:Nn \l__myverb_tl {#1}
    \tl_replace_all:Nnn \l__myverb_tl { ~ } { { ~ } }
    \group_begin:
      \use:c { verbatim<strong i="8">@font</strong> }
      \use:x { \tl_map_function:NN \l__myverb_tl \__myverb:n }
    \group_end:
  }
\ExplSyntaxOff
\documentclass{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\begin{document}
\verb|a--bgrüße ----c ``<''|

\myverb|a--bgrüße ----c ``<''|
\end{document}

Ok, segunda tentativa (o v arg mantém os caracteres ativos como estão):

Mas nem todos. Por exemplo, a citação aqui não está ativa:

~~~~
\ documentclass {artigo}
\ usepackage [ngerman] {babel}
\ begin {document}
"uma

\ ExplSyntaxOn
\ NewDocumentCommand {\ myverb} {mv}
{
\ tl_analysis_ show: n {# 1}
\ tl_analysis_ show: n {# 2}
}
\ ExplSyntaxOff

\ myverb {"a} |" a |
\ end {document}
~~~~

dá

~~~~
A lista de tokens contém os tokens:

"(caractere ativo = macro: -> prefixo @ ativo" ativo @ char ")
a (a letra a).
}

l.29 \ myverb {"a} |" a |

?
A lista de tokens contém os tokens:

" (o personagem ")
a (o personagem a).
}
~~~~

@ u-fischer, mas qual dessas duas saídas se deseja no 'texto literal'?

O caso não ativo "me parece o que o LaTeX costumava significar por 'literalmente'.

Mas talvez algumas pessoas esperem que o resultado seja, por exemplo, ä que não se parece muito com 'literalmente' para outras pessoas.

Como já escrevi tantas vezes: o que significa "literalmente" fora do ASCII de 7 bits imprimível?

@ car222222 meu exemplo é sobre entrada e não saída. Não estou enviando nada, apenas analisando a aparência do argumento capturado por xparse. A partir da documentação, eu esperava que o argumento deixasse os chars ativos como estão e convertesse todos os outros tokens para catcode 12 e os espaços para catcode 10. Mas, como alguns testes mostram, minha expectativa estava errada: chars ativos configurados com babel são convertidos para catcode 12 também pois o analisador de argumentos contém um \ dospecial.

Uma outra pergunta: este argumento v -type deve reduzir espaços consecutivos em um token (com catcode 10) ou preservar o número de espaços “literalmente”? Exatamente como deveria ser “literalmente” (não acho que esteja bem definido agora no manual)?

@ u-fischer Entrada / saída ?? Mas você respondeu minha pergunta implícita.

Você deseja manter o ativo “mas acho que literalmente deve produzir o não ativo“ para que nenhum ä glifo possa ser gerado.

Quando digo “eu acho”, quero dizer que isso é o que eu esperaria seguir do conceito original (40 anos atrás) de 'literalmente' em TeX / LaTeX.

Talvez esse conceito + definições precisem ser mudados, mas para quê exatamente?

Ou como @ RuixiZhang42 colocou: como literalmente é o século 21 literalmente?

Curiosamente verbo * | YZ | (com duas guias consecutivas) dá um único espaço
porque o verbo muda o catcode do espaço, mas não da guia.

Eu concordo que o argumento do tipo v (e "+ v" também) não está bem definido agora. Será que o
o seguinte faz sentido, usando uma tabela catcode?

• Dê catcode 13 (ativo) para espaços e alguns outros (`\ ^^ M por exemplo?).

• Dê catcode 12 (outro) a todos os outros bytes 0-127 (em pdfTeX), 0-255 (em XeTeX,
  upTeX, pTeX) ou 0-1114111 (LuaTeX).

• No pdfTeX, dê catcode 13 (ativo) aos bytes 128-255.

Talvez seja melhor manter algumas coisas como catcode 11 (letras)?

Você deseja manter o ativo “

Não, eu não disse isso. Só escrevi que esperava que isso acontecesse depois de ler a documentação. Isso significa apenas que a documentação precisa ser melhorada.

mas acho que literalmente deve produzir o não-ativo “para que nenhum ä glifo possa ser gerado.

Você pode obter "a como saída também com um " ativo: você só precisa dar a ele uma definição adequada localmente.

@ u-fischer Você pode obter "a como saída também com um ativo"

Claro, mas não sei se o 'modo literal' deve precisar dessa personalização? Talvez devesse?

De volta à pergunta: o que significa 'literalmente', tanto para ler uma lista de tokens de entrada quanto para saída (incluindo qual fonte, com quais ligaduras, kerning, outros recursos de fonte, etc., etc.).

Talvez algo assim (para entrada de ASCII imprimível apenas):
nenhum caractere é removido ou o código do caractere é alterado, catcode da maioria torna-se 12, exceto o seguinte, que é alterado para (ou mantido em) 13,. . . .
Além disso, os seguintes ascii não imprimíveis que também se tornam tokens catcode 13:. . .

O ambiente deve ser customizado para lidar com a saída (representação de texto) de qualquer caractere ACSII de 7 bits que pode, pelo processo acima, ser internamente um token catcode 13.

[Bastante diferente do original, mas ainda cobrindo apenas a entrada ASCII, como o original.]

@blefloch escreveu: No pdfTeX, dê catcode 13 (ativo) aos bytes 128-255.

Você faria isso mesmo se o inputenc não estivesse sendo usado? Que definição você daria a eles?

Não tenho certeza se alguém pensou muito sobre a entrada utf-8 inputenc para o modo textual. Isso terá suporte e o que significa?

Não tenho certeza se alguém pensou muito sobre a entrada utf-8 inputenc para o modo textual. Isso terá suporte e o que significa?

É suportado, pelo menos para codificação T1. Para grego ou similar, você teria que redefinir literalmente @ font :

~~~
\ documentclass {artigo}
\ usepackage [LGR, T1] {fontenc}
\ begin {document}
verbo | grüße € |

\ makeatletter
\ defverbatim @ font {\ ttfamily}
fontencoding {LGR} \ selectfont
verbo | Γειά σου Κόσμε |
\ end {document}
~~~

Possíveis sugestões sobre o que o argumento literal deve fazer. Eu tento para a opção 1, mas posso estar perdendo alguns aspectos.

1. Atualizar catcodes de 0 a 255 (em qualquer mecanismo), mantendo catcodes 11, 12, 13 (letra / outro / ativo) inalterado, alterando catcode 10 (espaço) para catcode 13 (ativo) e todos os outros catcodes para 12 (outro) . Em seguida, aplique as alterações de catcode em \@noligs , ou seja, torne os itens \verbatim@nolig@list ativos. Em seguida, pegue o argumento: isso dá um resultado com catcodes 11, 12, 13 apenas. É fácil converter de volta para uma string para usuários que não desejam caracteres ativos. Para aqueles que desejam entrada de dados ou suporte para abreviatura de babel, todos os caracteres ativos foram mantidos. Também apóia a supressão da ligadura.

2. Use uma tabela catcode \l_xparse_verbatim_cctab que pode ser alterada pelo usuário. Isso é difícil de manter em sincronia com os atalhos do babel que podem mudar no meio do documento. Também é complicado para o redator do pacote, uma vez que ele precisa ter uma função de empacotamento que altere \l_xparse_verbatim_cctab antes de analisar o argumento literal.

3. Variante de 2. onde o cctab é fornecido como um argumento v (argumento opcional ou nova letra). Novamente, isso não pode ser sincronizado com as abreviações do babel e as alterações no \verbatim@nolig@list .