Latex3: Clases de mensajes que se dice que son mensajes de "paquete"

Lo es, pero debe decirlo explícitamente agregando el tipo de su archivo a \g_msg_module_type_prop :

\prop_gput:Nnn \g_msg_module_type_prop { myclass } { Class }

y opcionalmente su nombre a \g_msg_module_name_prop :

\prop_gput:Nnn \g_msg_module_name_prop { myclass } { My~Nice~Class }

luego obtienes una advertencia como:

Class My Nice Class Warning: Bar

Quizás l3msg podría autocompletar el tipo si se usó \ProvidesExpl<Thing> ...

MWE:

\begin{filecontents*}[overwrite]{myclass.cls}
\ProvidesExplClass
  {myclass}
  {2021/04/26}
  {0.1}
  {
    My Nice Class
  }
\NeedsTeXFormat{LaTeX2e}
\LoadClass { article }
%
\prop_gput:Nnn \g_msg_module_type_prop { myclass } { Class }
\prop_gput:Nnn \g_msg_module_name_prop { myclass } { My~Nice~Class }
\msg_new:nnn {myclass} {Foo} {Bar}
\msg_warning:nn {myclass} {Foo}
\end{filecontents*}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\documentclass{myclass}
\begin{document}
\end{document}

Quizás l3msg podría autocompletar el tipo si se usó \ProvidesExpl<Thing> ...

¡Sería bueno! :sonrisa:

No existe una relación particular entre \ProvidesExpl... y el prefijo del módulo utilizado para el código: creo que es algo que uno tiene que hacer manualmente.

Eso es antes de todo el problema de 'realmente las clases no deberían usar expl3 sintaxis'; era una idea que no funciona del todo. (Las clases todavía necesitan mucho más trabajo, pero no deberían estar haciendo programación, que pertenece a los paquetes).

No existe una relación particular entre \ProvidesExpl... y el prefijo del módulo utilizado para el código: creo que es algo que uno tiene que hacer manualmente.

No veo por qué.

Eso es antes de todo el problema de 'realmente las clases no deberían usar expl3 sintaxis'; era una idea que no funciona del todo. (Las clases todavía necesitan mucho más trabajo, pero no deberían estar haciendo programación, que pertenece a los paquetes).

No entiendo cuál es la idea que no funciona del todo.

No existe una relación particular entre \ProvidesExpl... y el prefijo del módulo utilizado para el código: creo que es algo que uno tiene que hacer manualmente.

No veo por qué.

En \ProvidesExplClass el nombre de la clase no tiene por qué coincidir con el prefijo utilizado por el código. O el código podría ser utilizado tanto por un paquete como por una clase (lo hago en términos de LaTeX2e en achemso ), por lo que el enlace no sería evidente.

Eso es antes de todo el problema de 'realmente las clases no deberían usar expl3 sintaxis'; era una idea que no funciona del todo. (Las clases todavía necesitan mucho más trabajo, pero no deberían estar haciendo programación, que pertenece a los paquetes).

No entiendo cuál es la idea que no funciona del todo.

Las clases realmente deberían tratar sobre formato / estilo / etc., no sobre funcionalidad. Este último debe agregarse por paquetes, que idealmente serían independientes de las clases con las que se usan. La situación actual no es ideal, y al principio el conjunto \ProvidesExpl... se proporcionó para reflejar simplemente \Provides... del kernel de LaTeX2e. Pero en retrospectiva, ese es el enfoque incorrecto: _packages_ debería usar expl3 código, _classes_ debería usar interfaces de nivel de documento o diseño que _podría_ implementarse en expl3 .

Las clases realmente deberían tratar sobre formato / estilo / etc., no sobre funcionalidad.

La clase en la que estoy trabajando actualmente debería insertar un gráfico en la primera página del documento ... si se encuentra este gráfico y, de lo contrario, debería mostrar una advertencia (además de una advertencia en el archivo de registro). ¿Es diseño o funcionalidad?

Solucioné el problema actual moviendo la documentación de \g_msg_module_name_prop y \g_msg_module_type_prop antes en la documentación de l3msg .

@dbitouze Si bien estás haciendo una buena pregunta sobre diseño versus código, no creo que este tema sea el lugar correcto. ¿Quizás podría tener sentido publicar una pregunta en stackexchange y que uno de los miembros del equipo responda allí? O una pregunta en la lista de correo de LaTeX-L. Realmente no lo se.

Hecho .

Solucioné el problema actual moviendo la documentación de \g_msg_module_name_prop y \g_msg_module_type_prop antes en la documentación de l3msg .

AFAICS, el MCE en el OP todavía escribe:

Paquete myclass Advertencia: Bar

incluso con pdflatex-dev . Aquí está la salida en la terminal (más la lista de archivos):

This is pdfTeX, Version 3.141592653-2.6-1.40.22 (TeX Live 2021) (preloaded format=pdflatex-dev)
 restricted \write18 enabled.
entering extended mode
(./test.tex
LaTeX2e <2021-12-01> pre-release-0 (develop 2021-6-6 branch)
L3 programming layer <2021-06-01>

LaTeX Warning: Writing or overwriting file `./myclass.cls'.


(./myclass.cls
Document Class: myclass 2021/04/26 v0.1  My Nice Class 
(/usr/local/texlive/2021/texmf-dist/tex/latex-dev/base/article.cls
Document Class: article 2021/02/12 v1.4n Standard LaTeX document class
(/usr/local/texlive/2021/texmf-dist/tex/latex-dev/base/size10.clo))

Package myclass Warning: Bar

) (/usr/local/texlive/2021/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def)
 (./test.aux) (./test.aux)

 *File List*
 myclass.cls    2021/04/26 v0.1  My Nice Class 
 article.cls    2021/02/12 v1.4n Standard LaTeX document class
  size10.clo    2021/02/12 v1.4n Standard LaTeX file (size option)
l3backend-pdftex.def    2021-05-07 L3 backend support: PDF output (pdfTeX)
 ***********

 )
No pages of output.
Transcript written on test.log.

@dbitouze has aplicado

\prop_gput:Nnn \g_msg_module_type_prop { myclass } { Class }

Lo "arreglado" en el mensaje de Bruno fue mover la documentación antes para dejar en claro que tal línea necesita agregarse, no que ya no sea necesario.

@dbitouze has aplicado

\prop_gput:Nnn \g_msg_module_type_prop { myclass } { Class }

Hum, no, perdón por el malentendido.

Lo "arreglado" en el mensaje de Bruno fue mover la documentación antes para dejar en claro que tal línea necesita agregarse, no que ya no sea necesario.

Lástima: pensé (y esperaba) que la solución ya no requiriera ninguna acción por parte del autor de la clase: sonrisa: ¿Está planeado?

Como explicó @josephwright, no existe una conexión detectable automáticamente entre un prefijo utilizado y un nombre de clase o paquete. Esto no es realmente diferente del antiguo método 2e de decir explícitamente \ClassWarning y luego dar el nombre, solo que ahora debe definir la conexión solo una vez y en el pasado tenía que hacer esto en cada llamada usando un \Class... comando y darle el nombre de la clase.

Entonces, usar "myclass" es solo una cadena que se pasa al sistema msg y, si bien los humanos podríamos pensar que ver "class" en el nombre significa que es una clase, el sistema msg no puede hacer esa deducción (y puede que sea incorrecto de todos modos). Esta es la razón por la que se necesita la acción del autor de la clase y se necesitaba en el pasado cuando escribiste \ClassWarning{<classname>} . El hecho de que el nombre de la clase sea conocido por \ProvidesExplClass no significa que la cadena utilizada en msg esté usando ese nombre. Por ejemplo, la mayoría de los nombres de mis paquetes son largos, pero los prefijos que utilizo son bastante cortos. Por lo tanto, debe decirle al sistema de mensajes que una cadena en particular es una clase.

Podríamos hacer un seguimiento plausible cuando se llama a \ ProvidesExplClass y
\ g_msg_module_type_prop no se ha modificado entre el inicio y el final del
file (probablemente solo advierta si se ha llamado a \ msg_new: nnnn).

No suena demasiado feo y podría evitar este fácil error.

podríamos, pero es un costo de tiempo de ejecución para cada documento, mientras que el error es un error de clase que se manifiesta con una salida incorrecta (pero inofensiva) y se corrige fácilmente de una vez por todas. Así que no estoy realmente a favor de ralentizar el procesamiento con comprobaciones en tiempo de ejecución. En todo caso, debería ir a la opción de verificación. Sé que los costos de tiempo de ejecución son pequeños por sí mismos, pero en general se suman.