Latex3: Klassennachrichten, die angeblich "Paketnachrichten" sind

Ist es, aber Sie müssen es explizit angeben, indem Sie den Typ Ihrer Datei zu \g_msg_module_type_prop hinzufügen:

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

und optional seinen Namen zu \g_msg_module_name_prop :

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

dann erhalten Sie eine Warnung wie:

Class My Nice Class Warning: Bar

Vielleicht könnte l3msg den Typ automatisch ausfüllen, wenn \ProvidesExpl<Thing> verwendet wurde...

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}

Vielleicht könnte l3msg den Typ automatisch ausfüllen, wenn \ProvidesExpl<Thing> verwendet wurde...

Wäre nett! :Lächeln:

Es gibt keine besondere Beziehung zwischen \ProvidesExpl... und dem für den Code verwendeten Modulpräfix: Ich denke, es ist nur etwas, das man manuell tun muss.

Das ist, bevor das ganze Thema "Klassen sollten wirklich keine expl3 Syntax verwenden" - es war eine Idee, die nicht ganz funktioniert. (Klassen brauchen noch viel mehr Arbeit, sollten aber keine Programmierung machen, die in Pakete gehört.)

Es gibt keine besondere Beziehung zwischen \ProvidesExpl... und dem für den Code verwendeten Modulpräfix: Ich denke, es ist nur etwas, das man manuell tun muss.

Ich sehe nicht warum.

Das ist, bevor das ganze Thema "Klassen sollten wirklich keine expl3 Syntax verwenden" - es war eine Idee, die nicht ganz funktioniert. (Klassen brauchen noch viel mehr Arbeit, sollten aber keine Programmierung machen, die in Pakete gehört.)

Ich verstehe nicht, was die Idee ist, die nicht ganz funktioniert.

Es gibt keine besondere Beziehung zwischen \ProvidesExpl... und dem für den Code verwendeten Modulpräfix: Ich denke, es ist nur etwas, das man manuell tun muss.

Ich sehe nicht warum.

In \ProvidesExplClass der Name der Klasse nicht mit dem vom Code verwendeten Präfix übereinstimmen. Oder der Code könnte sowohl von einem Paket als auch von einer Klasse verwendet werden (ich mache das in LaTeX2e-Begriffen in achemso ), sodass der Link nicht sichtbar wäre.

Das ist, bevor das ganze Thema "Klassen sollten wirklich keine expl3 Syntax verwenden" - eine Idee, die nicht ganz funktioniert. (Klassen brauchen noch viel mehr Arbeit, sollten aber keine Programmierung machen, die in Pakete gehört.)

Ich verstehe nicht, was die Idee ist, die nicht ganz funktioniert.

Bei Klassen sollte es wirklich um Formatierung/Stil/etc. gehen, nicht um Funktionalität. Letztere sollten durch Pakete hinzugefügt werden, die idealerweise unabhängig von den Klassen sind, mit denen sie verwendet werden. Die aktuelle Situation ist nicht ideal, und schon früh wurde das \ProvidesExpl... Set bereitgestellt, um einfach \Provides... aus dem LaTeX2e-Kernel zu spiegeln. Aber im Nachhinein ist das der falsche Ansatz: _packages_ sollten expl3 Code verwenden, _classes_ sollten Schnittstellen auf Dokument- oder Designebene verwenden, die _möglicherweise_ in expl3 implementiert werden könnten.

Bei Klassen sollte es wirklich um Formatierung/Stil/etc. gehen, nicht um Funktionalität.

Die Klasse, an der ich gerade arbeite, sollte auf der ersten Seite des Dokuments eine Grafik einfügen... wenn diese Grafik gefunden wird und ansonsten eine Warnung anzeigen (zusätzlich zu einer Warnung in der Protokolldatei). Ist es Design oder Funktionalität?

Ich habe das vorliegende Problem behoben, indem ich die Dokumentation von \g_msg_module_name_prop und \g_msg_module_type_prop in die l3msg Dokumentation verschoben habe.

@dbitouze Während Sie eine gute Frage zu Design vs. Code stellen, denke ich, dass dieses Thema nicht der richtige Ort ist. Vielleicht könnte es sinnvoll sein, eine Frage auf Stackexchange zu stellen und dort von einem der Teammitglieder antworten zu lassen? Oder eine Frage auf der LaTeX-L-Mailingliste. Ich weiß es nicht wirklich.

Fertig .

Ich habe das vorliegende Problem behoben, indem ich die Dokumentation von \g_msg_module_name_prop und \g_msg_module_type_prop in die l3msg Dokumentation verschoben habe.

AFAICS, das MCE im OP schreibt noch:

Paket myclass Warnung: Bar

sogar mit pdflatex-dev . Hier die Ausgabe im Terminal (plus Dateiliste):

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 hast du dich beworben

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

Das "behobene" in Brunos Nachricht bestand darin, die Dokumentation früher zu verschieben, um klarzustellen, dass eine solche Zeile hinzugefügt werden muss und nicht, dass eine solche Zeile nicht mehr benötigt wird.

@dbitouze hast du dich beworben

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

Hm, nein, sorry für das Missverständnis.

Das "behobene" in Brunos Nachricht bestand darin, die Dokumentation früher zu verschieben, um klarzustellen, dass eine solche Zeile hinzugefügt werden muss und nicht, dass eine solche Zeile nicht mehr benötigt wird.

Schade: Ich dachte (und hoffte), dass der Fix keine Aktion des Klassenautors mehr erfordert :smile: Ist das geplant?

Wie @josephwright erklärt hat, gibt es keine automatisch erkennbare Verbindung zwischen einem verwendeten Präfix und einem Klassen- oder Paketnamen. Dies unterscheidet sich nicht wirklich von der alten 2e-Methode, explizit \ClassWarning sagen und dann den Namen zu geben, nur muss man die Verbindung jetzt nur einmal definieren und in der Vergangenheit musste man dies bei jedem Anruf mit a . tun \Class... Befehl und geben Sie ihm den Klassennamen.

Die Verwendung von "myclass" ist also nur ein String, der an das msg-System übergeben wird, und während wir Menschen denken könnten, dass "class" im Namen bedeutet, dass es sich um eine Klasse handelt, kann das msg-System diese Schlussfolgerung nicht ziehen (und sie kann sowieso falsch sein). Aus diesem Grund ist eine Aktion des Klassenautors erforderlich und war in der Vergangenheit erforderlich, wo Sie \ClassWarning{<classname>} . Die Tatsache, dass \ProvidesExplClass den Klassennamen bekannt ist, bedeutet nicht, dass der in msg verwendete String diesen Namen verwendet. Zum Beispiel sind die meisten meiner Paketnamen lang, aber die Präfixe, die ich verwende, sind ziemlich kurz. Sie müssen dem msg-System also mitteilen, dass ein bestimmter String eine Klasse ist.

Wir könnten plausibel den Überblick behalten, wenn \ProvidesExplClass aufgerufen wird und
\g_msg_module_type_prop wurde zwischen Anfang und Ende des nicht geändert
(wahrscheinlich nur warnen, wenn \msg_new:nnnn aufgerufen wurde).

Es klingt nicht zu hässlich und könnte diesen einfachen Fehler vermeiden.

wir könnten, aber es kostet jedes Dokument Laufzeit, während der Fehler ein Klassenfehler ist, der sich mit einer falschen (aber harmlosen) Ausgabe manifestiert und ein für alle Mal leicht korrigiert werden kann. Ich bin also nicht wirklich dafür, die Verarbeitung durch Laufzeitprüfungen zu verlangsamen. Wenn überhaupt, sollte es in die Check-Option gehen. Ich weiß, dass diese Laufzeitkosten an sich winzig sind, aber insgesamt summieren sie sich.