Classes messages claimed to be "Package" messages

[dbitouze]

As shown by the following MCE, classes messages are claimed to be "Package" messages:

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

writes:

Package myclass Warning: Bar

Shouldn't the l3msg module be able to distinguish between \ProvidesExplClass and \ProvidesExplPackage?

[PhelypeOleinik]

It is, but you have to tell it explicitly by adding the type of your file to \g_msg_module_type_prop:

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

and optionally its name to \g_msg_module_name_prop:

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

then you get a warning like:

Class My Nice Class Warning: Bar

Maybe l3msg could auto-fill the type if \ProvidesExpl<Thing> was used...

---

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}

[dbitouze]

Maybe l3msg could auto-fill the type if \ProvidesExpl<Thing> was used...

Would be nice! 😄

[josephwright]

There's no particular relationship between \ProvidesExpl... and the module prefix used for code: I think it's just something one has to do manually.

That's before the whole 'really classes shouldn't use expl3 syntax' issue - it was an idea that doesn't quite work. (Classes still need a lot more work, but shouldn't be doing programming, which belongs in packages.)

[dbitouze]

There's no particular relationship between \ProvidesExpl... and the module prefix used for code: I think it's just something one has to do manually.

I don't see why.

That's before the whole 'really classes shouldn't use expl3 syntax' issue - it was an idea that doesn't quite work. (Classes still need a lot more work, but shouldn't be doing programming, which belongs in packages.)

I don't understand what's the idea that doesn't quite work.

[josephwright]

There's no particular relationship between \ProvidesExpl... and the module prefix used for code: I think it's just something one has to do manually.

I don't see why.

In \ProvidesExplClass the name of the class doesn't have to match the prefix used by the code. Or the code could be used by both a package and a class (I do that in LaTeX2e terms in achemso), so the link would not be apparent.

That's before the whole 'really classes shouldn't use expl3 syntax' issue - it was an idea that doesn't quite work. (Classes still need a lot more work, but shouldn't be doing programming, which belongs in packages.)

I don't understand what's the idea that doesn't quite work.

Classes really should be about formatting/style/etc., not functionality. The latter should be added by packages, which ideally would be independent of the classes they are used with. The current situation is not ideal, and early on the \ProvidesExpl... set were provided to simply mirror \Provides... from the LaTeX2e kernel. But with hindsight that's the wrong approach: packages should be using expl3 code, classes should be using document- or design-level interfaces which might be implemented in expl3.

[dbitouze]

Classes really should be about formatting/style/etc., not functionality.

The class I'm currently working on should insert a graphic on the first page of the document... if this graphic is found and otherwise should display an admonition (in addition to a warning in the log file). Is it design or functionality?

[blefloch]

I've fixed the issue at hand by moving the documentation of \g_msg_module_name_prop and \g_msg_module_type_prop earlier in the l3msg documentation.

@dbitouze While you're asking a good question on design vs code, I don't think this issue is the right place. Perhaps it could make sense to post a question on stackexchange and have one of the team members answer there? Or a question on the LaTeX-L mailing list. I don't really know.

[dbitouze]

Done.

[dbitouze]

I've fixed the issue at hand by moving the documentation of \g_msg_module_name_prop and \g_msg_module_type_prop earlier in the l3msg documentation.

AFAICS, the MCE in the OP still writes:

Package myclass Warning: Bar

even with pdflatex-dev. Here is the output in the terminal (plus the file list):

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.

[FrankMittelbach]

@dbitouze have you applied

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

The "fixed" in Bruno's message was to move the documentation earlier to make it clear that such a line needs adding not that such a ine is no longer needed.

[dbitouze]

@dbitouze have you applied

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

Hum, no, sorry for the misunderstanding.

The "fixed" in Bruno's message was to move the documentation earlier to make it clear that such a line needs adding not that such a ine is no longer needed.

Too bad: I thought (and hoped) the fix didn't require anymore any action from the class author 😄 Is it planned?

[FrankMittelbach]

As @josephwright explained there is no automatically detectable connection between a prefix used and a class or package name. This is not really different from the old 2e method of explicitly saying \ClassWarning and then giving the name, only now you have to define the connection only once and in the past you had to do this on every call by using a \Class... command and giving the class name to it.

So using "myclass" is just a string passed to the msg system and while we humans might think seeing "class" in the name means it is a class the msg system can't make that deduction (and it may be wrong anyway). This is why action from the class author is needed and was needed in the past where you wrote \ClassWarning{<classname>}. The fact that the class name is known to \ProvidesExplClass doesn't mean that the string used in msg is using that name. For example most of my package names are long but the prefixes I use are fairly short. So you have to tell the msg system that a particular string is a class.

[blefloch]

We could plausibly keep track when \ProvidesExplClass is called and \g_msg_module_type_prop has not been modified between the start and end of the file (probably only warn if \msg_new:nnnn has been called). It doesn't sound too ugly, and it could avoid this easy mistake.

[FrankMittelbach]

we could, but it is a runtime cost for every document while the error is a class error that manifests itself with wrong (but harmless ) output and is easily corrected once and for all. So I'm not really in favor of slowing down processing with runtime checks. If at all it should go into the check option. I know this runtime costs are all tiny by itself but overll they add up.