Latex3: Классы сообщений, заявленных как "Пакетные" сообщения

Это так, но вы должны указать это явно, добавив тип вашего файла в \g_msg_module_type_prop :

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

и, возможно, его имя на \g_msg_module_name_prop :

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

тогда вы получите предупреждение вроде:

Class My Nice Class Warning: Bar

Возможно, l3msg сможет автоматически заполнить тип, если использовалось \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}

Возможно, l3msg сможет автоматически заполнить тип, если использовалось \ProvidesExpl<Thing> ...

Было бы здорово! :улыбка:

Нет особой взаимосвязи между \ProvidesExpl... и префиксом модуля, используемым для кода: я думаю, что это просто то, что нужно делать вручную.

Это до того, как вся проблема «действительно классы не должны использовать синтаксис expl3 » - это была идея, которая не совсем сработала. (Классы по-прежнему нуждаются в гораздо большей работе, но не должны заниматься программированием, которое принадлежит пакетам.)

Нет особой взаимосвязи между \ProvidesExpl... и префиксом модуля, используемым для кода: я думаю, что это просто то, что нужно делать вручную.

Не понимаю почему.

Это до того, как вся проблема «действительно классы не должны использовать синтаксис expl3 » - это была идея, которая не совсем сработала. (Классы по-прежнему нуждаются в гораздо большей работе, но не должны заниматься программированием, которое принадлежит пакетам.)

Я не понимаю, в чем идея, что не совсем работает.

Нет особой взаимосвязи между \ProvidesExpl... и префиксом модуля, используемым для кода: я думаю, что это просто то, что нужно делать вручную.

Не понимаю почему.

В \ProvidesExplClass имя класса не обязательно должно совпадать с префиксом, используемым кодом. Или код может использоваться как пакетом, так и классом (я делаю это в терминах LaTeX2e в achemso ), поэтому ссылка не будет очевидна.

Это до того, как вся проблема «действительно классы не должны использовать синтаксис expl3 » - это была идея, которая не совсем сработала. (Классы по-прежнему нуждаются в гораздо большей работе, но не должны заниматься программированием, которое принадлежит пакетам.)

Я не понимаю, в чем идея, что не совсем работает.

Классы действительно должны касаться форматирования / стиля / и т. Д., А не функциональности. Последние должны добавляться пакетами, которые в идеале не должны зависеть от классов, с которыми они используются. Текущая ситуация не идеальна, и вначале набор \ProvidesExpl... был предоставлен для простого зеркалирования \Provides... из ядра LaTeX2e. Но задним числом это неправильный подход: _packages_ должен использовать expl3 code, _classes_ должны использовать интерфейсы уровня документа или дизайна, которые _might_ могут быть реализованы в expl3 .

Классы действительно должны касаться форматирования / стиля / и т. Д., А не функциональности.

Класс, над которым я сейчас работаю, должен вставить рисунок на первую страницу документа ... если этот рисунок найден, а в противном случае должен отображать предупреждение (в дополнение к предупреждению в файле журнала). Дизайн или функциональность?

Я исправил возникшую проблему, переместив документацию \g_msg_module_name_prop и \g_msg_module_type_prop ранее в документацию l3msg .

@dbitouze Хотя вы задаете хороший вопрос о дизайне и коде, я не думаю, что эта проблема - подходящее место. Возможно, имеет смысл опубликовать вопрос о stackexchange и попросить одного из членов команды там ответить? Или вопрос по списку рассылки LaTeX-L. Я точно не знаю.

Готово .

Я исправил возникшую проблему, переместив документацию \g_msg_module_name_prop и \g_msg_module_type_prop ранее в документацию l3msg .

AFAICS, MCE в OP по-прежнему пишет:

Предупреждение о пакете myclass: панель

даже с pdflatex-dev . Вот результат в терминале (плюс список файлов):

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 вы подали заявку

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

«Исправлено» в сообщении Бруно было переместить документацию раньше, чтобы было ясно, что такая строка нуждается в добавлении, а не о том, что такая строка больше не нужна.

@dbitouze вы подали заявку

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

Хм, нет, извините за недоразумение.

«Исправлено» в сообщении Бруно было переместить документацию раньше, чтобы было ясно, что такая строка нуждается в добавлении, а не о том, что такая строка больше не нужна.

Жаль: я думал (и надеялся), что исправление больше не требует никаких действий со стороны автора класса: smile: Это запланировано?

Как объяснил @josephwright, не существует автоматически обнаруживаемой связи между используемым префиксом и именем класса или пакета. Это на самом деле не отличается от старого метода 2e, в котором \ClassWarning явно указывается с последующим присвоением имени, только теперь вам нужно определять соединение только один раз, а в прошлом вам приходилось делать это при каждом вызове, используя \Class... и присвоив ей имя класса.

Таким образом, использование «myclass» - это просто строка, переданная в систему msg, и хотя мы, люди, могли бы подумать, что вид «class» в имени означает, что это класс, система msg не может сделать такой вывод (и это может быть в любом случае неверным). Вот почему необходимо действие от автора класса, и оно было необходимо в прошлом, когда вы писали \ClassWarning{<classname>} . Тот факт, что имя класса известно \ProvidesExplClass , не означает, что строка, используемая в msg, использует это имя. Например, большинство моих имен пакетов длинные, но префиксы, которые я использую, довольно короткие. Таким образом, вы должны сообщить системе msg, что конкретная строка является классом.

Мы могли бы правдоподобно отслеживать, когда вызывается \ ProvidesExplClass и
\ g_msg_module_type_prop не был изменен между началом и концом
файл (вероятно, только предупредить, если был вызван \ msg_new: nnnn).

Это звучит не слишком уродливо, и с его помощью можно было бы избежать этой простой ошибки.

мы могли бы, но это затраты времени выполнения для каждого документа, в то время как ошибка является ошибкой класса, которая проявляется в неправильном (но безвредном) выводе и легко исправляется раз и навсегда. Так что я не совсем сторонник замедления обработки с помощью проверок во время выполнения. Если вообще он должен войти в опцию проверки. Я знаю, что все эти затраты времени выполнения крошечные сами по себе, но в сумме они складываются.