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

\ProvidesExpl<Thing>が使用された場合、 l3msgがタイプを自動入力できる可能性があります...

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}

\ProvidesExpl<Thing>が使用された場合、 l3msgがタイプを自動入力できる可能性があります...

いいだろう！ ：笑顔：

\ProvidesExpl...と、コードに使用されるモジュールプレフィックスとの間に特別な関係はありません。これは、手動で行う必要があることだと思います。

これは、「実際にはクラス全体がexpl3構文を使用するべきではない」問題の前です-それは完全には機能しないアイデアでした。 （クラスにはまだ多くの作業が必要ですが、パッケージに属するプログラミングを行うべきではありません。）

\ProvidesExpl...と、コードに使用されるモジュールプレフィックスとの間に特別な関係はありません。これは、手動で行う必要があることだと思います。

理由がわかりません。

これは、「実際にはクラス全体がexpl3構文を使用するべきではない」問題の前です-それは完全には機能しないアイデアでした。 （クラスにはまだ多くの作業が必要ですが、パッケージに属するプログラミングを行うべきではありません。）

うまくいかないアイデアが何なのかわかりません。

\ProvidesExpl...と、コードに使用されるモジュールプレフィックスとの間に特別な関係はありません。これは、手動で行う必要があることだと思います。

理由がわかりません。

\ProvidesExplClassでは、クラスの名前はコードで使用されるプレフィックスと一致する必要はありません。 または、コードをパッケージとクラスの両方で使用できるため（LaTeX2eの用語ではachemso ）、リンクはわかりません。

これは、「実際にはクラス全体がexpl3構文を使用するべきではない」問題の前です-それは完全には機能しないアイデアでした。 （クラスにはまだ多くの作業が必要ですが、パッケージに属するプログラミングを行うべきではありません。）

うまくいかないアイデアが何なのかわかりません。

クラスは実際には、機能ではなく、フォーマット/スタイルなどに関するものでなければなりません。 後者はパッケージによって追加する必要があります。パッケージは、使用するクラスから独立しているのが理想的です。 現在の状況は理想的ではなく、初期の\ProvidesExpl...セットは、LaTeX2eカーネルからの\Provides...を単純にミラーリングするために提供されていました。 しかし、後から考えると、これは間違ったアプローチです。_packages_はexpl3コードを使用する必要があり、_classes_はexpl3実装される可能性のあるドキュメントレベルまたはデザインレベルのインターフェイスを使用する必要があります。

クラスは実際には、機能ではなく、フォーマット/スタイルなどに関するものでなければなりません。

私が現在取り組んでいるクラスは、ドキュメントの最初のページにグラフィックを挿入する必要があります...このグラフィックが見つかった場合、それ以外の場合は（ログファイルの警告に加えて）警告を表示する必要があります。 デザインですか、それとも機能ですか？

\g_msg_module_name_propと\g_msg_module_type_prop l3msgドキュメントを

@dbitouzeデザインとコードについて良い質問をしている間、この問題は適切な場所ではないと思います。 おそらく、stackexchangeに質問を投稿して、チームメンバーの1人にそこで回答してもらうのは理にかなっていますか？ または、LaTeX-Lメーリングリストに関する質問。 よくわかりません。

完了。

\g_msg_module_name_propと\g_msg_module_type_prop l3msgドキュメントを

AFAICS、OPのMCEはまだ次のように書いています。

パッケージ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 }

ブルーノのメッセージの「修正済み」は、ドキュメントを以前に移動して、そのような行を追加する必要があることを明確にすることでした。そのようなineはもはや必要ないということではありません。

@dbitouze申請しましたか

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

うーん、いや、誤解してすみません。

ブルーノのメッセージの「修正済み」は、ドキュメントを以前に移動して、そのような行を追加する必要があることを明確にすることでした。そのようなineはもはや必要ないということではありません。

残念：修正にはクラスの作成者からのアクションはもう必要ないと思いました（そして期待していました）：smile：計画されていますか？

@josephwrightが説明したように、使用されるプレフィックスとクラスまたはパッケージ名の間に自動的に検出可能な接続はありません。 これは、明示的に\ClassWarningと言ってから名前を付ける、古い2eの方法と実際には違いはありません。接続を定義する必要があるのは一度だけで、以前は、 \Class...コマンドとそれにクラス名を付けます。

したがって、「myclass」の使用はmsgシステムに渡される文字列であり、名前に「class」が含まれていると、msgシステムがその推論を行うことができないクラスであると人間が考えるかもしれません（とにかく間違っている可能性があります）。 これが、クラスの作成者によるアクションが必要であり、過去に\ClassWarning{<classname>}ときに必要だった理由です。 クラス名が\ProvidesExplClass知られているという事実は、msgで使用されている文字列がその名前を使用していることを意味するわけではありません。 たとえば、私のパッケージ名のほとんどは長いですが、使用するプレフィックスはかなり短いです。 したがって、特定の文字列がクラスであることをmsgシステムに通知する必要があります。

\ ProvidesExplClassが呼び出され、
\ g_msg_module_type_propは、開始と終了の間で変更されていません
ファイル（おそらく\ msg_new：nnnnが呼び出された場合にのみ警告します）。

あまり醜く聞こえないので、この簡単な間違いを避けることができます。

可能ですが、それはすべてのドキュメントの実行時間コストですが、エラーはクラスエラーであり、間違った（ただし無害な）出力で現れ、簡単に修正できます。 したがって、ランタイムチェックを使用して処理を遅くすることにあまり賛成していません。 仮にあったとしても、それはチェックオプションに入るはずです。 このランタイムコストはそれ自体ではすべて小さいことを知っていますが、合計すると過剰になります。