Latex3: Documentar catcodes para el tipo de argumento "textual" de xparse, documentar cómo reproducir \ verb

Creado en 25 jun. 2020  ·  43Comentarios  ·  Fuente: latex3/latex3

Cuando fontenc se carga con su opción T1 , \NewDocumentCommand con un argumento literal devora el primer - si su contenido contiene un -- (independientemente de los delimitadores utilizados):

\documentclass{article}
\usepackage[T1]{fontenc}
\usepackage{xparse}
\NewDocumentCommand {\myverb} { v } {#1}
\begin{document}
\ttfamily
\verb|--all|

\myverb{-all}

\myverb{--all}

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

image

bug documentation xparse

Comentario más útil

Independientemente del resultado de esta discusión, será útil documentar en
xparse.pdf cómo reproducir el comportamiento del verbo usando \ NewDocumentCommand.

Todos 43 comentarios

Lo que está viendo es la ligadura -- en la fuente de la máquina de escribir. Si escribe \texttt{--} también verá un solo guión, pero si copia del PDF, verá que de hecho es un guión en blanco. Puede verificar eso alimentando el argumento capturado a \showtokens o usando \@noligs (LaTeX usa eso en \verb para tener -- 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}

test

pero se supone que v en xparse es palabra por palabra (¿no es así?) y en LaTeX eso significa máquina de escribir con ligaduras suprimidas, así que v debería hacerlo también en mi opinión.

Simplemente toma palabra por palabra (palabra por palabra aquí es un equivalente de \let\do\<strong i="5">@makeother</strong> \dospecials ). \@noligs podría agregarse en la configuración de catcode para escanear el argumento. Por otro lado, esto insertaría tokens activos donde (teóricamente) solo hay tokens de catcode u otros, por lo que en caso de que el argumento se use para algo diferente a la composición tipográfica, podría ser problemático.

Quizás alguna forma de permitir que el comando agregue su propia configuración de catcode, como:

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

@FrankMittelbach Estoy de acuerdo con PhelypeOleinik en que "palabra por palabra" significa "tomar lo que el usuario haya escrito palabra por palabra". La ligadura <hyphen hyphen> a <endash> es más una "característica de fuente" que un "error de captura de argumentos". Además, \ttfamily no significa "fuente monoespaciada = sin ligadura". Algunos tipos de letra monoespaciados se pueden usar como tipo de cuerpo (no solo código), por lo que las ligaduras de guiones no deben suprimirse en tales casos.

¿Pero no se supone que \NewDocumentCommand {\myverb} { v } {#1}\myverb{--all} comporta como \verb|--all| ?

@dbitouze - en realidad no. \ verb tiene dos partes: captura de argumentos y formateo. La configuración "v" en \ NewDocumentCommand solo hace lo primero.

@Phelype : a menos que me falte algo, ¿tu sugerencia no hace más que esto ?:

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

En ese caso, no creo que sea necesario. Entonces, volviendo a @dbitouze , la forma de replicar \ verb es algo como:

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

El jueves 25 de junio de 2020 a las 08:22, Denis Bitouzé [email protected]
escribió:

Pero, ¿no se supone \ NewDocumentCommand {\ myverb} {v} {# 1} \ myverb {- all}?
comportarse como \ verb | --todos |?

-

No exactamente, ya que v trata solo de analizar el argumento, y eso se lee
palabra por palabra, el verbo también compone el contenido en una fuente monoespaciada no estándar
configuración que suprime las ligaduras.
así que en lugar de solo #1 para componer el argumento en la fuente actual,
necesito hacer

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

excepto que \ @noligs requiere
\ defverbatim @ nolig @ list {\ do` \ do \ <\ do> \ do \, \ do \ '\ do-}
estar activo, por lo que podríamos considerar hacer v establecerlos como activos. o
proporcionando una envoltura alrededor de scantokens que organiza que \ @noligs puede funcionar
aquí

Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/latex3/latex3/issues/756#issuecomment-649302149 , o
darse de baja
https://github.com/notifications/unsubscribe-auth/AAJVYAVLBB4ABB3DD5TETRDRYL3MPANCNFSM4OHMH74A
.

@dbitouze no, la similitud está solo en la forma en que se puede delimitar el argumento: puedes usar \ myverb! abc !. El resultado se documenta como

lo que dará como resultado que el argumento capturado consta de tokens de los códigos de categoría 12 ("otro") y 13 ("activo"), excepto los espacios, a los que se les asigna el código de categoría 10 ("espacio").

El analizador de argumentos solo lee un argumento, no lo escribe. Y no tendría sentido agregarle comandos de fuente u otros comandos o incluso preprocesarlo para aplicar \@noligs de forma predeterminada: hay otras formas de suprimir las ligaduras. Con luatex se aplicaría quizás Ligatures=Resetall y con pdflatex se podría usar \pdfnoligatures con una fuente ligeramente diferente:

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

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

\ begin {document}
--todo

verbo | --todos |

\ myverb {-todos}

\ myverb {- todos}

\ myverb {--- todos}

\ footnotesize
--todos \ myverb {- todos}

\ ttfamily
--todo

verbo | --todos |

\ myverb {-todos}

\ myverb {- todos}

\ myverb {--- todos}

\ footnotesize
--todos \ myverb {- todos}

\ end {documento}
~~~~

@phelype : a menos que me falte algo, ¿tu sugerencia no hace más que esto ?:
\ NewDocumentCommand {\ myverb} {v} {{\ @noligs # 1}}

@wspr Algo así , pero no: \@noligs cambia el código de gato de - (y muchos otros) a 13, y luego defínalo como \def-{\leavevmode\kern\z@\char`-} : siendo un cambio de código de gato, tiene que hacerse antes de que se tome el argumento (a menos que estemos considerando \scantokens ), por lo tanto, mi sugerencia de permitir un argumento de "configuración de código de gato" en v (aunque tendría que ser opcional: \NewDocumentCommand {\myverb} { v[\@noligs] } {#1} ).

Gracias @phelype , ha pasado un tiempo desde que miré dentro de esa macro :)
En ese caso, me gusta la idea del argumento de configuración ... incluso si en este caso otros enfoques también pueden funcionar para deshabilitar las ligaduras.

No tenemos datos opcionales en la especificación arg, por lo que necesitaría una nueva letra ( w ?)

O un cambio rotundo a v -type

Preferiría votar por V (coincidiendo con que tenemos o, O y d y D) y luego considerar un cambio radical.

No tenemos datos opcionales en la especificación arg, por lo que necesitaría una nueva letra ( w ?)

¿No podemos agregar uno?

O quizás, dado que tenemos o y O{} , parece natural tener v y V{} . Por supuesto, el argumento significaría cosas diferentes ...

En mi humilde opinión, si los catcodes fueran personalizables para el tipo v, tendría sentido usar el código cctab, y no algún comando arbitrario como \@noligs . Entonces, la lectura del comando solo establecería los catcodes y las definiciones de los caracteres activos deberían hacerse en el cuerpo de la macro.

@ u-fischer Así que mejor consigo ese PR por l3cctab en ...

Actualmente, no tengo idea de cómo funciona l3cctab y cómo podría ser útil para el problema actual, pero estoy realmente interesado :)

Mi punto fue que semánticamente v es 'palabra por palabra' mientras que lo que se necesita aquí no lo es. Es importante destacar que debe preocuparse si los caracteres delimitadores son alterados por la tabla catcode o lo que sea. Además, hemos sido coherentes con las letras mayúsculas -> alguna variante de arg opcional de una minúscula. Entonces diría que algo como c{<table>} (= 'catcode') sería correcto.

Ordenaré las cosas cctab hoy o mañana si puedo, para que podamos discutir.

@dbitouze Una tabla catcode es una forma de tener un conjunto 'fijo' de catcode para todos los caracteres (*). Significa que obtiene una interfaz de un token para los cambios, por lo que ' \c_document_cctab para catcodes normales, \c_initex_cctab para IniTeX, etc. La idea es que esto es mucho más claro y confiable que uno- ajuste por uno.

  • En XeTeX, no tenemos la primitiva necesaria, por lo que solo puedo cubrir los caracteres 0 a 255 con un rendimiento razonable.

@josephwright (fuera del tema) Me parece que querías agregar una nota al pie, pero Markdown no lo sabía.

La supresión de un conjunto conocido de ligaduras durante la salida también se puede hacer usando \tl_replace_all:Nnn y reemplazando el carácter problemático con algo que no formará la ligadura.

@Skillmon Buen punto: uno podría tomar el material textualmente y reemplazar los tokens. Como todo es estrictamente literal, probablemente sea un enfoque más fácil que preocuparse por la configuración de catcode.

Independientemente del resultado de esta discusión, será útil documentar en
xparse.pdf cómo reproducir el comportamiento del verbo usando \ NewDocumentCommand.

@josephwright dependiendo de la cantidad de tokens que se reemplazarán, el rendimiento será mucho peor con el enfoque \tl_replace_all:Nnn .

Además, ¿cómo sabrá qué caracteres (en una fuente muy grande) deben reemplazarse?

Además: ¿qué significa la composición tipográfica 'palabra por palabra con una fuente monoespaciada' para muchas escrituras (no europeas)?

@ car222222 en una fuente muy grande, tienes las características de la fuente como la única forma razonable de suprimirlas todas, LaTeX no puede conocer todas las ligaduras posibles en una fuente. Pero al menos los caracteres compatibles con LaTeX2e podrían cubrirse fácilmente (es solo un \tl_map_function:NN y \tl_replace_all:Nnn ).

Además: AFAIK, hay símbolos a doble espacio en algunas fuentes monoespaciadas para algunas escrituras no europeas.

Sugeriría simplemente envolver cada personaje en un hbox. Parece funcionar
razonablemente bien, pero no probé mucho.

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

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

Sugeriría simplemente envolver cada personaje en un hbox. Parece funcionar razonablemente bien, pero no probé mucho.

Prueba con |a--bgrüße ---c ``<''|

Ok, segundo intento (el v arg mantiene los caracteres activos como están): inserte \kern 0pt\relax antes de todos los caracteres no activos.

\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, segundo intento (el v arg mantiene los caracteres activos como están):

Pero no todo el mundo. Por ejemplo, la cita aquí no está activa:

~~~~
\ documentclass {artículo}
\ usepackage [ngerman] {babel}
\ begin {document}
"a

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

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

da

~~~~
La lista de tokens contiene los tokens:

"(carácter activo = macro: -> active @prefix " active @ char ")
a (la letra a).
}

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

?
La lista de tokens contiene los tokens:

" (el personaje ")
a (el personaje a).
}
~~~~

@ u-fischer, pero ¿cuál de estas dos salidas quiere uno en el 'texto literal'?

El caso "No activo" me parece a lo que LaTeX solía decir con "palabra por palabra".

Pero tal vez algunas personas esperan que el resultado sea, por ejemplo, ä que no se parece mucho a "palabra por palabra" para otras personas.

Como he escrito tantas veces: ¿qué significa "palabra por palabra" fuera de ASCII imprimible de 7 bits?

@ car222222 mi ejemplo es sobre entrada, no salida. No estoy generando nada, solo analizo cómo se ve el argumento capturado por xparse. De la documentación, esperaba que el argumento dejara los caracteres activos como están y convirtiera todos los demás tokens en catcode 12 y los espacios en catcode 10. Pero como algunas pruebas muestran que mi expectativa era incorrecta: la configuración de los caracteres activos con babel también se convierte a catcode 12 ya que el analizador de argumentos contiene un \ dospecial.

Otra pregunta: ¿Debería este argumento v -type colapsar espacios consecutivos en un token (con catcode 10), o preservar el número de espacios "textualmente"? ¿Exactamente qué tan “palabra por palabra” debería ser (no creo que esté bien definido en este momento en el manual)?

@ u-fischer Entrada / salida ?? Pero respondiste a mi pregunta implícita.

Desea mantener el activo "pero creo que palabra por palabra debería producir el no activo" para que no se pueda generar ningún glifo ä.

Cuando digo "yo pienso" quiero decir que esto es lo que esperaría seguir del concepto original (hace 40 años) de 'palabra por palabra' en TeX / LaTeX.

Tal vez sea necesario cambiar ese concepto + definiciones, pero ¿a qué exactamente?

O como dijo @ RuixiZhang42 : ¿cuán literalmente es el siglo XXI?

Curiosamente el verbo * | YZ | (con dos pestañas consecutivas) da un solo espacio
porque el verbo cambia el catcode del espacio pero no del tabulador.

Estoy de acuerdo en que el argumento de tipo v (y "+ v" también) no está bien definido en este momento. ¿El
siguiente tiene sentido, usando una tabla de catcode?

  • Dale catcode 13 (activo) a los espacios y algunos otros (`\ ^^ M, por ejemplo?).

  • Dar catcode 12 (otro) a todos los demás bytes 0-127 (en pdfTeX), 0-255 (en XeTeX,
    upTeX, pTeX) o 0-1114111 (LuaTeX).

  • En pdfTeX, proporcione catcode 13 (activo) a los bytes 128-255.

¿Quizás es mejor mantener algunas cosas como catcode 11 (letras)?

Quieres mantenerte activo "

No, no dije eso. Solo escribí que esperaba que esto sucediera después de leer la documentación. Esto solo implica que la documentación necesita mejorar.

pero creo que palabra por palabra debería producir el no activo “para que no se pueda generar ningún glifo ä.

Puede obtener "a como salida también con un " activo: solo necesita darle localmente una definición adecuada.

@ u-fischer Puede obtener "una salida como también con una activa"

Claro, pero no sé si el 'modo literal' debería necesitar tal personalización. ¿Quizás debería?

Volviendo a la pregunta: ¿qué significa 'palabra por palabra', tanto para leer una lista de tokens de entrada como para la salida (incluyendo qué fuente, con qué ligaduras, kerning, otras características de fuente, etc., etc.).

Tal vez algo como esto (solo para la entrada de ASCII imprimible):
no se elimina ningún carácter o se cambia el código de carácter, el código cat de la mayoría se convierte en 12, excepto los siguientes, que se cambian a (o se mantienen en) 13,. . . .
Además de los siguientes ascii no imprimibles que también se convierten en tokens de catcode 13:. . .

El entorno debe personalizarse para manejar la salida (representación de texto) de cualquier carácter ACSII de 7 bits que, mediante el proceso anterior, resulte ser internamente un token catcode 13.

[Bastante diferente al original, pero aún cubre solo la entrada ASCII, como el original].

@blefloch escribió: En pdfTeX, proporcione catcode 13 (activo) a los bytes 128-255.

¿Haría esto incluso si no se utiliza inputenc? ¿Qué definición les daría?

No estoy seguro de si alguien ha pensado mucho en la entrada de utf-8 inputenc al modo literal. ¿Se apoyará esto y qué significa?

No estoy seguro de si alguien ha pensado mucho en la entrada de utf-8 inputenc al modo literal. ¿Se apoyará esto y qué significa?

Es compatible, al menos para la codificación T1. Para griego o similar, tendría que redefinir palabra por palabra @ fuente :

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

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

image

Posibles sugerencias sobre lo que debería hacer el argumento literal. Tiendo hacia la opción 1, pero es posible que me falten algunos aspectos.

  1. Actualice los catcodes de 0 a 255 (en cualquier motor), manteniendo los catcodes 11, 12, 13 (letra / otro / activo) sin cambios, cambiando el catcode 10 (espacio) a catcode 13 (activo) y todos los demás catcodes a 12 (otro) . Luego aplique los cambios de código de gato en \@noligs , es decir, active los elementos de \verbatim@nolig@list . Luego tome el argumento: esto da un resultado con catcodes 11, 12, 13 solamente. Es fácil volver a convertir a una cadena para los usuarios que no quieren caracteres activos. Para aquellos que deseen compatibilidad con inputenc o babel-taquigrafía, se han mantenido todos los caracteres activos. También es compatible con la supresión de ligaduras.

  2. Utilice una tabla de código de gato \l_xparse_verbatim_cctab que el usuario pueda cambiar. Esto es difícil de mantener sincronizado con los atajos de babel que pueden cambiar a mitad del documento. También es difícil de manejar para el escritor de paquetes, ya que necesitan tener una función contenedora que cambie \l_xparse_verbatim_cctab antes de analizar el argumento textualmente.

  3. Variante de 2. donde cctab se da como argumento v (argumento opcional o nueva letra). Nuevamente, esto no se puede mantener sincronizado con las abreviaturas de babel y los cambios en \verbatim@nolig@list .

¿Fue útil esta página
0 / 5 - 0 calificaciones

Temas relacionados

EvanAad picture EvanAad  ·  49Comentarios

stone-zeng picture stone-zeng  ·  25Comentarios

dbitouze picture dbitouze  ·  8Comentarios

josephwright picture josephwright  ·  12Comentarios

dbitouze picture dbitouze  ·  4Comentarios