Latex3: Mensagens de aulas que afirmam ser mensagens de "Pacote"

É, mas você tem que dizer explicitamente adicionando o tipo do seu arquivo a \g_msg_module_type_prop :

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

e opcionalmente seu nome para \g_msg_module_name_prop :

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

então você recebe um aviso como:

Class My Nice Class Warning: Bar

Talvez l3msg pudesse preencher automaticamente o tipo se \ProvidesExpl<Thing> fosse usado ...

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}

Talvez l3msg pudesse preencher automaticamente o tipo se \ProvidesExpl<Thing> fosse usado ...

Seria bom! :sorriso:

Não há uma relação particular entre \ProvidesExpl... e o prefixo do módulo usado para o código: acho que é apenas algo que se tem que fazer manualmente.

Isso antes de todo o problema de 'realmente as classes não deveriam usar expl3 sintaxe' - era uma ideia que não funcionou muito bem. (As classes ainda precisam de muito mais trabalho, mas não deveriam fazer programação, que pertence aos pacotes.)

Não há uma relação particular entre \ProvidesExpl... e o prefixo do módulo usado para o código: acho que é apenas algo que se tem que fazer manualmente.

Não vejo por quê.

Isso antes de todo o problema de 'realmente as classes não deveriam usar expl3 sintaxe' - era uma ideia que não funcionou muito bem. (As classes ainda precisam de muito mais trabalho, mas não deveriam fazer programação, que pertence aos pacotes.)

Não entendo qual é a ideia que não funciona.

Não há uma relação particular entre \ProvidesExpl... e o prefixo do módulo usado para o código: acho que é apenas algo que se tem que fazer manualmente.

Não vejo por quê.

Em \ProvidesExplClass o nome da classe não precisa corresponder ao prefixo usado pelo código. Ou o código poderia ser usado por um pacote e uma classe (eu faço isso em termos de LaTeX2e em achemso ), então o link não seria aparente.

Isso antes de todo o problema de 'realmente as classes não deveriam usar expl3 sintaxe' - era uma ideia que não funcionava muito bem. (As classes ainda precisam de muito mais trabalho, mas não deveriam fazer programação, que pertence aos pacotes.)

Não entendo qual é a ideia que não funciona.

As aulas realmente deveriam ser sobre formatação / estilo / etc., Não funcionalidade. Este último deve ser adicionado por pacotes, que idealmente seriam independentes das classes com as quais são usados. A situação atual não é ideal e, no início, o conjunto \ProvidesExpl... foi fornecido para simplesmente espelhar \Provides... do kernel LaTeX2e. Mas olhando para trás, essa é a abordagem errada: _pacotes_ deveriam estar usando código expl3 , _classes_ deveriam estar usando interfaces em nível de documento ou design que _podem_ ser implementadas em expl3 .

As aulas realmente deveriam ser sobre formatação / estilo / etc., Não funcionalidade.

A aula em que estou trabalhando no momento deve inserir um gráfico na primeira página do documento ... se esse gráfico for encontrado e, caso contrário, deve exibir uma advertência (além de um aviso no arquivo de log). É design ou funcionalidade?

Corrigi o problema em questão movendo a documentação de \g_msg_module_name_prop e \g_msg_module_type_prop anteriormente na documentação l3msg .

@dbitouze Embora você esteja fazendo uma boa pergunta sobre design vs código, não acho que esse problema seja o lugar certo. Talvez faça sentido postar uma pergunta no stackexchange e ter um dos membros da equipe respondendo lá? Ou uma pergunta na lista de e-mails do LaTeX-L. Eu realmente não sei.

Pronto .

Corrigi o problema em questão movendo a documentação de \g_msg_module_name_prop e \g_msg_module_type_prop anteriormente na documentação l3msg .

AFAICS, o MCE no OP ainda escreve:

Aviso do pacote myclass: Barra

mesmo com pdflatex-dev . Aqui está a saída no terminal (mais a lista de arquivos):

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 você se inscreveu

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

O "consertado" na mensagem de Bruno era mover a documentação mais cedo para deixar claro que tal linha precisa ser adicionada, não que tal linha não seja mais necessária.

@dbitouze você se inscreveu

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

Hum, não, desculpe pelo mal-entendido.

O "consertado" na mensagem de Bruno era mover a documentação mais cedo para deixar claro que tal linha precisa ser adicionada, não que tal linha não seja mais necessária.

Que pena: pensei (e esperava) que a correção não exigisse mais nenhuma ação do autor da classe: sorria: Está planejado?

Como @josephwright explicou, não há conexão detectável automaticamente entre um prefixo usado e um nome de classe ou pacote. Isso não é realmente diferente do antigo método 2e de dizer explicitamente \ClassWarning e, em seguida, fornecer o nome, só que agora você tem que definir a conexão apenas uma vez e no passado você tinha que fazer isso em todas as chamadas usando um \Class... comando e dando o nome da classe a ele.

Portanto, usar "myclass" é apenas uma string passada para o sistema de msg e, embora nós, humanos, possamos pensar que ver "classe" no nome significa que é uma classe, o sistema de msg não pode fazer essa dedução (e pode estar errado de qualquer maneira). É por isso que a ação do autor da classe é necessária e era necessária no passado onde você escreveu \ClassWarning{<classname>} . O fato de o nome da classe ser conhecido por \ProvidesExplClass não significa que a string usada na msg está usando esse nome. Por exemplo, a maioria dos nomes de meus pacotes são longos, mas os prefixos que uso são bastante curtos. Portanto, você deve informar ao sistema de msg que uma determinada string é uma classe.

Poderíamos, de forma plausível, acompanhar quando \ ProvidesExplClass é chamado e
\ g_msg_module_type_prop não foi modificado entre o início e o fim do
(provavelmente só avisa se \ msg_new: nnnn foi chamado).

Não parece muito feio e pode evitar esse erro fácil.

poderíamos, mas é um custo de tempo de execução para cada documento, enquanto o erro é um erro de classe que se manifesta com saída errada (mas inofensiva) e é facilmente corrigido de uma vez por todas. Portanto, não sou a favor de desacelerar o processamento com verificações de tempo de execução. Se for o caso, deve ir para a opção de verificação. Eu sei que os custos desse tempo de execução são minúsculos por si só, mas com certeza eles se somam.