Latex3: \msg_term Nachrichten sagen nicht, woher sie kommen

Ich bin nicht sehr vertraut mit l3msg , aber ich denke, dass dies beabsichtigt ist. Wenn Sie eine "Info"-Nachricht wünschen, können Sie diese mit \msg_info:nn (aber dann ins Protokoll).

\msg_info:nn (aber dann geht es ins Log).

Das ist der Punkt: AFAICT, es ist ziemlich üblich, im Terminal einige Info-Meldungen zu sehen, die perfekt identifizierbar sind.

Die Designentscheidung hier war, dass die meisten Meldungen Fehler/Warnungen/Infos sind und sowohl an das Terminal als auch an das Protokoll gesendet werden sollten. Die beiden 'untergeordneten' Funktionen, \msg_term:nn und \msg_log:nn , sind ziemlich spezialisiert und sollen 'nicht laut' sein.

Die meisten Nachrichten sind Fehler/Warnungen/Infos und sollten sowohl an das Terminal als auch an das Protokoll gesendet werden.

Aber genau, Info-Meldungen gehen nur ins Log:

\msg_ info:nnnnnn {⟨Modul ⟩} {⟨Nachricht ⟩} {⟨arg eins ⟩} {⟨arg zwei ⟩} {⟨arg drei ⟩} {⟨arg vier ⟩}

Gibt ⟨Modul⟩-Informationen ⟨Nachricht⟩ aus und übergibt ⟨Arg Eins⟩ bis ⟨Arg Vier⟩ an die Texterstellung
Funktionen. Der Informationstext wird der Protokolldatei hinzugefügt.

@dbitouze Ah, sorry, ja: Info ist nur im Log, wie du sagst. Das Ziel bei den "rohen" Nachrichten war, dass es sich eher um sehr niedriges Material handelt, bei dem kein zusätzliches "Rauschen" erforderlich ist. Um ehrlich zu sein, haben wir sie nicht wirklich oft "in freier Wildbahn" gesehen - ich denke, was ich im Nachhinein frage, sind Anwendungsfälle. (Für wirklich Low-Level-Zeug würde ich sowieso \iow_log:n / \iow_term:n .)

@josephwright Ich neige dazu, zuzustimmen, dass "Info" wie "Warnung" sein sollte, mit dem Unterschied, dass es nicht auf dem Terminal

@FrankMittelbach Das ist der Fall: Die Frage war, ich denke an \msg_log:nn , das weniger (keine) Formatierung vornimmt. Wir könnten wohl \msg_log:nn und \msg_term:nn , da sie sich wirklich etwas zwischen dem Nachrichtensystem befinden und einfach Zeilen in das Protokoll schreiben.

Zwei getrennte Fragen vermischen sich hier ein wenig.

• Formatierte Nachrichten: Aktuell haben wir Fehler/Warnungen/Infos, mit der letzten
  taucht nur im Log auf. @dbitouze bittet um eine
  auch Terminal. Vielleicht kann er ja einen konkreten Fall klären, wo eine solche Meldung
  soll nicht nur eine Warnmeldung sein?

• Unformatierte Nachrichten: \msg_ log:nn und \msg_ term:nn. Ich habe keine Meinung dazu
  ob man sie behält.

ok, ich habe offensichtlich das falsche Ende des Sticks erwischt und die Anfrage falsch gelesen. In diesem Fall würde ich sagen, dass sich das normale 2e-Verhalten nicht ändern sollte (und das Nachrichtensystem ist für 2e, auch wenn wir hier im expl3-Repo sind)

@dbitouze fragt auch nach einer Info-Nachricht auf dem Terminal. Vielleicht kann er einen konkreten Fall klären, in dem eine solche Meldung nicht nur eine Warnmeldung sein soll?

Manchmal möchte man den Benutzer über etwas informieren, ihn aber nicht mit einer Warnung erschrecken.

Ich stimme dem zu – konzeptionell denke ich, dass diese Botschaften zwei Achsen haben: wo sie erscheinen und wie schwerwiegend sie sind.

Nehmen wir an, ich habe eine Diagnoseausgabe (geringfügig nützlich, aber nicht nutzlos) aus der Verarbeitung einiger Dinge, und ich sende sie standardmäßig an die Protokolldatei. Es mag manchmal nett sein, es auf der Konsole anzuzeigen (eine "ausführliche" Benutzeroption), aber es wäre falsch, diese Dinge als Warnungen zu bezeichnen.

Ich unterstütze das, aber ich glaube nicht, dass wir wirklich eine zweite Achse wollen. Fehler + Warnungen sollten immer imho auf dem Terminal + Log gemeldet werden, nur zur Info scheint es wirklich zwei Klassen zu geben Info (nur Log) und Begriff-Info.

Beachten Sie, dass separate Achsen sowieso sehr hilfreich wären, da wir normalerweise nicht möchten, dass alle Infos plötzlich zu Begriffs-Infos werden (was Sie sowieso durch Zuordnen von Info zu Begriffs-Infos tun könnten), sondern normalerweise nur einige Infos, um auch immer zum Terminal, also würde ich in Betracht ziehen, eine weitere Kategorie terminfo und einige entsprechende \msg_terminfo:nn hinzuzufügen, damit Sie Ihre Absichten für das Standardverhalten im Code deutlich machen können, ohne dies im msg-Setup etwas versteckt setzen zu müssen .