Latex3: Los mensajes \ msg_term no dicen de dónde vienen

Creado en 11 may. 2021  ·  12Comentarios  ·  Fuente: latex3/latex3

Como se muestra en el siguiente MCE, los mensajes \msg_term no dicen de dónde vienen (a diferencia de los mensajes \msg_warning ):

\begin{filecontents*}[overwrite]{mypackage.sty}
\ProvidesExplPackage
  {mypackage}
  {2021-05-11}
  {0.1}
  {
    My Nice package
  }
\NeedsTeXFormat{LaTeX2e}
%
\msg_new:nnn {mypackage} {Foo} {FOOBAR}
\msg_warning:nn {mypackage} {Foo}
\msg_term:nn {mypackage} {Foo}
\end{filecontents*}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\documentclass{article}
\usepackage{mypackage}
\begin{document}
\end{document}

escribe:

Paquete mypackage Advertencia: FOOBAR

FOOBAR

mientras que, para este último, cabría esperar:

Paquete mypackage Info: FOOBAR

decision-needed

Comentario más útil

En cierto modo lo secundo, pero no creo que realmente queramos un segundo eje. Los errores + advertencias siempre deben informarse en mi humilde opinión en el terminal + registro, solo para información parece que en realidad hay dos clases info (solo registro) y term-info.

Tenga en cuenta que tener ejes separados ayudaría mucho de todos modos, porque normalmente no queremos que todas las infos se conviertan repentinamente en infos de término (lo que de todos modos podría hacer al mapear información a term-info) pero, por lo general, solo algunas infos también irán siempre al terminal, por lo que consideraría agregar una categoría adicional terminfo y algunos \msg_terminfo:nn para que pueda aclarar sus intenciones para el comportamiento predeterminado en el código sin la necesidad de establecer eso algo oculto en la configuración de msg .

Todos 12 comentarios

No estoy muy familiarizado con l3msg , pero creo que esto es por diseño. Si desea un mensaje de "Información", puede obtenerlo usando \msg_info:nn (pero luego va al registro).

\msg_info:nn (pero luego va al registro).

Ese es el punto: AFAICT, es bastante común ver en el terminal algunos mensajes Info que son perfectamente identificables.

La decisión de diseño aquí fue que la mayoría de los mensajes son de error / advertencia / información y deben ir tanto al terminal como al registro. Las dos funciones de 'nivel inferior', \msg_term:nn y \msg_log:nn , son bastante especializadas y están destinadas a ser 'no ruidosas'.

la mayoría de los mensajes son de error / advertencia / información y deben ir tanto al terminal como al registro.

Pero precisamente, los mensajes de información van solo al registro:

\ msg_ info: nnnnnn {⟨module⟩} {⟨mensaje⟩} {⟨arg uno⟩} {⟨arg dos⟩} {⟨arg tres⟩} {⟨arg cuatro⟩}

Emite el ⟨mensaje⟩ de información del ⟨módulo⟩, pasando ⟨arg uno⟩ a ⟨arg cuatro⟩ al elemento de creación de texto
funciones. El texto de información se agrega al archivo de registro.

@dbitouze Ah, lo siento, sí: la información está solo en el registro como usted dice. El objetivo de los mensajes "sin procesar" era que era más probable que fueran mensajes de muy bajo nivel donde no se requiere "ruido" adicional. Para ser honesto, no hemos visto que se utilicen mucho 'en la naturaleza'; supongo que lo que me pregunto en retrospectiva son los casos de uso. (Para cosas de nivel realmente bajo, usaría \iow_log:n / \iow_term:n todos modos).

@josephwright Tiendo a estar de acuerdo en que "info" debería tener como "advertencia" con la diferencia de que no se muestra en la terminal pero no que registra las cosas de manera diferente. Por ejemplo, las advertencias generalmente se formatean con saltos de línea explícitos basados ​​en la idea de que hay algún prefijo "(módulo)" en las siguientes líneas y cuando cambio un grupo de advertencia a información, creo que todo lo que debería cambiar es dónde se muestra, no cómo .

@FrankMittelbach Ese es el caso: la pregunta era que pienso en \msg_log:nn , que hace menos (no) formateo. Podría decirse que podríamos eliminar \msg_log:nn y \msg_term:nn , ya que en realidad están algo entre el sistema de mensajes y simplemente volcando líneas en el registro.

Dos preguntas distintas se mezclan un poco aquí.

  • Mensajes formateados: actualmente tenemos error / advertencia / información, con el último
    solo aparece en el registro. @dbitouze solicita un mensaje de información que aparece en el
    terminal también. Tal vez pueda aclarar un caso concreto en el que tal mensaje
    ¿No debería ser simplemente un mensaje de advertencia?

  • Mensajes sin formato: \ msg_ log: nn y \ msg_ term: nn. No tengo opinión sobre
    si conservarlos.

ok, obviamente obtuve el extremo equivocado del palo y leí la solicitud incorrectamente. En ese caso, diría que no debería haber ningún cambio en el comportamiento normal de 2e (y el sistema de mensajería es para 2e incluso si estamos aquí en el repositorio expl3)

@dbitouze también solicita un mensaje de información que aparece en el terminal. ¿Quizás pueda aclarar un caso concreto en el que tal mensaje no debería ser simplemente un mensaje de advertencia?

A veces quieres informar al usuario sobre algo pero no asustarlo con una advertencia.

Estoy de acuerdo con esto: conceptualmente creo que hay dos ejes en estos mensajes: dónde aparecen y qué tan severos son.

Digamos que tengo algún resultado de diagnóstico (marginalmente útil pero no inútil) del procesamiento de algunas cosas, y lo envío al archivo de registro de forma predeterminada. Mostrarlo en la consola puede ser agradable a veces (una opción de usuario "detallada") pero sería incorrecto llamar a estas cosas advertencias.

En cierto modo lo secundo, pero no creo que realmente queramos un segundo eje. Los errores + advertencias siempre deben informarse en mi humilde opinión en el terminal + registro, solo para información parece que en realidad hay dos clases info (solo registro) y term-info.

Tenga en cuenta que tener ejes separados ayudaría mucho de todos modos, porque normalmente no queremos que todas las infos se conviertan repentinamente en infos de término (lo que de todos modos podría hacer al mapear información a term-info) pero, por lo general, solo algunas infos también irán siempre al terminal, por lo que consideraría agregar una categoría adicional terminfo y algunos \msg_terminfo:nn para que pueda aclarar sus intenciones para el comportamiento predeterminado en el código sin la necesidad de establecer eso algo oculto en la configuración de msg .

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