次のMCEに示されているように、 \msg_termメッセージは、（ \msg_warningメッセージとは異なり）どこから来たのかを示しません。
\begin{filecontents*}[overwrite]{mypackage.sty}
\ProvidesExplPackage
{mypackage}
{2021-05-11}
{0.1}
{
My Nice package
}
\NeedsTeXFormat{LaTeX2e}
%
\msg_new:nnn {mypackage} {Foo} {FOOBAR}
\msg_warning:nn {mypackage} {Foo}
\msg_term:nn {mypackage} {Foo}
\end{filecontents*}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\documentclass{article}
\usepackage{mypackage}
\begin{document}
\end{document}
書き込み：
パッケージmypackage警告：FOOBAR
FOOBAR
一方、後者の場合、次のことが予想されます。
パッケージmypackage情報：FOOBAR
dbitouze
全てのコメント12件
私はl3msgにあまり詳しくありませんが、これは仕様によるものだと思います。 「情報」メッセージが必要な場合は、 \msg_info:nnを使用して取得できます（ただし、ログに移動します）。
blefloch
2021年05月11日
\msg_info:nn（ただし、ログに移動します）。
それがポイントです：AFAICT、ターミナルで完全に識別可能ないくつかの情報メッセージを見るのはかなり一般的です。
dbitouze
2021年05月11日
ここでの設計上の決定は、ほとんどのメッセージはエラー/警告/情報であり、端末とログの両方に送信する必要があるというものでした。 2つの「低レベル」関数\msg_term:nnと\msg_log:nnはかなり特殊化されており、「ノイズがない」ことを目的としています。
josephwright
2021年05月11日
ほとんどのメッセージはエラー/警告/情報であり、端末とログの両方に送信する必要があります。
しかし正確には、情報メッセージはログにのみ送信されます。
\ msg_ info：nnnnnn {⟨module⟩} {⟨message⟩} {⟨argone⟩} {⟨argtwo⟩} {⟨argthree⟩} {⟨argfour⟩}
⟨モジュール⟩情報⟨メッセージ⟩を発行し、⟨argone⟩から⟨argfour⟩をテキスト作成に渡します
関数。 情報テキストがログファイルに追加されます。
dbitouze
2021年05月11日
@dbitouzeああ、すみません、はい：あなたが言うように情報はただログにあります。 「生の」メッセージの目的は、追加の「ノイズ」が必要とされない非常に低レベルのものである可能性が高いことでした。 正直なところ、「実際に」それらがあまり使用されているのを見たことがありません。後から考えて疑問に思うのは、ユースケースだと思います。 （本当に低レベルのものについては、とにかく\iow_log:n / \iow_term:nます。）
josephwright
2021年05月11日
@josephwright私は、「情報」は「警告」のようにすべきであることに同意する傾向がありますが、端末には表示されませんが、ログが異なるという違いはありません。 たとえば、警告は通常、次の行に「（モジュール）」プレフィックスがあるという考えに基づいて、明示的な改行でフォーマットされます。グループを警告から情報に変更すると、変更する必要があるのは、表示される場所だけであり、どのように表示されるかではないと思います。 。
FrankMittelbach
2021年05月11日
@FrankMittelbachその場合です。問題は、フォーマットが少ない（ない） \msg_log:nnについて考えること\msg_log:nnと\msg_term:nnは、実際にはメッセージシステムとログへの行のダンプの中間にあるため、おそらく削除できます。
josephwright
2021年05月11日
ここでは、2つの別々の質問が少し混同されています。
blefloch
2021年05月11日
わかりました、私は明らかにスティックの間違った端を手に入れ、リクエストを間違って読みました。 その場合、通常の2eの動作に変更はないはずです（そして、expl3リポジトリにいる場合でもメッセージングシステムは2e用です）
FrankMittelbach
2021年05月11日
@dbitouzeは、端末にも表示される情報メッセージを要求します。 たぶん彼は、そのようなメッセージが単なる警告メッセージであってはならない具体的なケースを明確にすることができますか？
ユーザーに何かを知らせたいが、警告で怖がらせたくない場合があります。
dbitouze
2021年05月18日
私はこれに同意します—概念的には、これらのメッセージには2つの軸があると思います。メッセージが表示される場所と重大度です。
いくつかのものを処理することで診断（わずかに役立つが役に立たない）出力があり、それをデフォルトでログファイルに送信するとします。 コンソールに表示するのは良い場合もありますが（「詳細な」ユーザーオプション）、これらを警告と呼ぶのは誤りです。
wspr
2021年05月18日
私はそれを少し秒で言いますが、私たちは本当に2番目の軸が必要だとは思いません。 エラー+警告は常にターミナル+ログでimhoに報告する必要があります。情報についてのみ、実際にはinfo（ログのみ）とterm-infoの2つのクラスがあるようです。
通常、すべての情報が突然用語情報になることは望ましくないため（情報を用語情報にマッピングすることで可能です）、通常は一部の情報だけが常にターミナルなので、さらにカテゴリterminfoとそれに対応する\msg_terminfo:nn追加することを検討します。これにより、メッセージの設定で多少隠された設定をしなくても、コードでデフォルトの動作の意図を明確にすることができます。 。
FrankMittelbach
2021年05月18日
関連する問題
dbitouze
·
14コメント
stone-zeng
·
25コメント
josephwright
·
12コメント
tail-reversion
·
8コメント
EvanAad
·
49コメント
最も参考になるコメント
私はそれを少し秒で言いますが、私たちは本当に2番目の軸が必要だとは思いません。 エラー+警告は常にターミナル+ログでimhoに報告する必要があります。情報についてのみ、実際にはinfo（ログのみ）とterm-infoの2つのクラスがあるようです。
通常、すべての情報が突然用語情報になることは望ましくないため（情報を用語情報にマッピングすることで可能です）、通常は一部の情報だけが常にターミナルなので、さらにカテゴリ
terminfoとそれに対応する\msg_terminfo:nn追加することを検討します。これにより、メッセージの設定で多少隠された設定をしなくても、コードでデフォルトの動作の意図を明確にすることができます。 。