Latex3: Messages de classes prétendus être des messages « Package »

C'est le cas, mais vous devez le dire explicitement en ajoutant le type de votre fichier à \g_msg_module_type_prop :

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

et éventuellement son nom en \g_msg_module_name_prop :

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

alors vous obtenez un avertissement comme :

Class My Nice Class Warning: Bar

Peut-être que l3msg pourrait remplir automatiquement le type si \ProvidesExpl<Thing> était utilisé...

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}

Peut-être que l3msg pourrait remplir automatiquement le type si \ProvidesExpl<Thing> était utilisé...

Ce serait sympa ! :le sourire:

Il n'y a pas de relation particulière entre \ProvidesExpl... et le préfixe de module utilisé pour le code : je pense que c'est juste quelque chose qu'il faut faire manuellement.

C'était avant tout le problème « les classes ne devraient pas vraiment utiliser la syntaxe expl3 » - c'était une idée qui ne fonctionnait pas tout à fait. (Les classes ont encore besoin de beaucoup plus de travail, mais ne devraient pas faire de programmation, qui appartient aux packages.)

Il n'y a pas de relation particulière entre \ProvidesExpl... et le préfixe de module utilisé pour le code : je pense que c'est juste quelque chose qu'il faut faire manuellement.

Je ne vois pas pourquoi.

C'était avant tout le problème « les classes ne devraient pas vraiment utiliser la syntaxe expl3 » - c'était une idée qui ne fonctionnait pas tout à fait. (Les classes ont encore besoin de beaucoup plus de travail, mais ne devraient pas faire de programmation, qui appartient aux packages.)

Je ne comprends pas quelle est l'idée qui ne fonctionne pas tout à fait.

Il n'y a pas de relation particulière entre \ProvidesExpl... et le préfixe de module utilisé pour le code : je pense que c'est juste quelque chose qu'il faut faire manuellement.

Je ne vois pas pourquoi.

Dans \ProvidesExplClass le nom de la classe ne doit pas nécessairement correspondre au préfixe utilisé par le code. Ou le code pourrait être utilisé à la fois par un package et une classe (je le fais en termes LaTeX2e en achemso ), donc le lien ne serait pas apparent.

C'était avant tout le problème « les classes ne devraient pas vraiment utiliser la syntaxe expl3 » - c'était une idée qui ne fonctionnait pas tout à fait. (Les classes ont encore besoin de beaucoup plus de travail, mais ne devraient pas faire de programmation, qui appartient aux packages.)

Je ne comprends pas quelle est l'idée qui ne fonctionne pas tout à fait.

Les classes devraient vraiment concerner le formatage/le style/etc., pas la fonctionnalité. Ces derniers devraient être ajoutés par des packages, qui seraient idéalement indépendants des classes avec lesquelles ils sont utilisés. La situation actuelle n'est pas idéale, et au début, l'ensemble \ProvidesExpl... a été fourni pour simplement refléter \Provides... partir du noyau LaTeX2e. Mais avec le recul, c'est une mauvaise approche : _packages_ devrait utiliser du code expl3 , _classes_ devrait utiliser des interfaces au niveau du document ou de la conception qui _pourraient_ être implémentées dans expl3 .

Les classes devraient vraiment concerner le formatage/le style/etc., pas la fonctionnalité.

La classe sur laquelle je travaille actuellement devrait insérer un graphique sur la première page du document... si ce graphique est trouvé et sinon devrait afficher un avertissement (en plus d'un avertissement dans le fichier journal). Est-ce design ou fonctionnalité ?

J'ai résolu le problème en déplaçant la documentation de \g_msg_module_name_prop et \g_msg_module_type_prop plus tôt dans la documentation l3msg .

@dbitouze Alors que vous posez une bonne question sur la conception par rapport au code, je ne pense pas que ce problème soit au bon endroit. Peut-être qu'il serait judicieux de poster une question sur stackexchange et de demander à l'un des membres de l'équipe d'y répondre ? Ou une question sur la liste de diffusion LaTeX-L. Je ne sais pas vraiment.

Fait .

J'ai résolu le problème en déplaçant la documentation de \g_msg_module_name_prop et \g_msg_module_type_prop plus tôt dans la documentation l3msg .

AFAICS, le MCE dans l'OP écrit toujours :

Avertissement du paquet myclass : Bar

même avec pdflatex-dev . Voici la sortie dans le terminal (plus la liste des fichiers) :

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 as-tu postulé

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

Le "réparé" dans le message de Bruno était de déplacer la documentation plus tôt pour indiquer clairement qu'une telle ligne doit être ajoutée et non qu'une telle ine n'est plus nécessaire.

@dbitouze as-tu postulé

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

Hum, non, désolé pour le malentendu.

Le "réparé" dans le message de Bruno était de déplacer la documentation plus tôt pour indiquer clairement qu'une telle ligne doit être ajoutée et non qu'une telle ine n'est plus nécessaire.

Dommage : je pensais (et espérais) que le correctif ne nécessitait plus aucune action de la part de l'auteur de la classe :smile: Est-ce que c'est prévu ?

Comme @josephwright l'a expliqué, il n'y a pas de connexion automatiquement détectable entre un préfixe utilisé et un nom de classe ou de package. Ce n'est pas vraiment différent de l'ancienne méthode 2e consistant à dire explicitement \ClassWarning puis à donner le nom, seulement maintenant vous devez définir la connexion une seule fois et dans le passé vous deviez le faire à chaque appel en utilisant un \Class... et en lui donnant le nom de la classe.

Donc, utiliser "myclass" n'est qu'une chaîne transmise au système msg et bien que nous, les humains, puissions penser que voir "class" dans le nom signifie qu'il s'agit d'une classe, le système msg ne peut pas faire cette déduction (et cela peut être faux de toute façon). C'est pourquoi l'action de l'auteur de la classe est nécessaire et était nécessaire dans le passé où vous avez écrit \ClassWarning{<classname>} . Le fait que le nom de la classe soit connu de \ProvidesExplClass ne signifie pas que la chaîne utilisée dans msg utilise ce nom. Par exemple, la plupart de mes noms de packages sont longs mais les préfixes que j'utilise sont assez courts. Vous devez donc dire au système msg qu'une chaîne particulière est une classe.

Nous pourrions vraisemblablement garder une trace lorsque \ProvidesExplClass est appelé et
\g_msg_module_type_prop n'a pas été modifié entre le début et la fin du
fichier (probablement seulement avertir si \msg_new:nnnn a été appelé).

Cela ne semble pas trop moche, et cela pourrait éviter cette erreur facile.

nous pourrions, mais c'est un coût d'exécution pour chaque document tandis que l'erreur est une erreur de classe qui se manifeste avec une sortie erronée (mais inoffensive) et est facilement corrigée une fois pour toutes. Je ne suis donc pas vraiment favorable à un ralentissement du traitement avec des contrôles d'exécution. Le cas échéant, cela devrait aller dans l'option de vérification. Je sais que ces coûts d'exécution sont minuscules en eux-mêmes, mais ils s'additionnent.