Latex3: \msg_term les messages ne disent pas d'où ils viennent

Je ne suis pas très familier avec l3msg , mais je pense que c'est par conception. Si vous voulez un message "Info", il peut être obtenu en utilisant \msg_info:nn (mais il va ensuite dans le journal).

\msg_info:nn (mais il va ensuite dans le journal).

C'est le but : AFAICT, il est assez fréquent de voir dans le terminal des messages d'Info parfaitement identifiables.

La décision de conception ici était que la plupart des messages sont des erreurs/avertissements/informations, et doivent aller à la fois au terminal et au journal. Les deux fonctions de « niveau inférieur », \msg_term:nn et \msg_log:nn , sont assez spécialisées et sont censées être « pas bruyantes ».

la plupart des messages sont des erreurs/avertissements/informations et doivent être envoyés à la fois au terminal et au journal.

Mais justement, les messages d'info ne vont qu'au log :

\msg_ info:nnnnnn {⟨module ⟩} {⟨message ⟩} {⟨arg un ⟩} {⟨arg deux ⟩} {⟨arg trois ⟩} {⟨arg quatre ⟩}

Émet des informations sur le ⟨module⟩ message⟩, en passant ⟨arg one⟩ à ⟨arg four au créateur de texte
les fonctions. Le texte d'information est ajouté au fichier journal.

@dbitouze Ah, désolé, oui: les informations sont juste dans le journal comme vous le dites. L'objectif avec les messages « bruts » était qu'ils sont plus susceptibles d'être des éléments de très bas niveau où un « bruit » supplémentaire n'est pas nécessaire. Pour être honnête, nous ne les avons pas vraiment vus beaucoup utilisés «dans la nature» - je suppose que ce que je m'interroge avec le recul, ce sont les cas d'utilisation. (Pour des trucs de très bas niveau, j'utiliserais de toute façon \iow_log:n / \iow_term:n .)

@josephwright J'ai tendance à convenir que "info" devrait être comme "avertissement" à la différence qu'il ne s'affiche pas sur le terminal mais pas qu'il enregistre les choses différemment. Par exemple, les avertissements sont généralement formatés avec des sauts de ligne explicites basés sur l'idée qu'il y a un préfixe "(module)" sur les lignes suivantes et lorsque je change un groupe d'avertissement en info, je pense que tout ce qui devrait changer est où il apparaît pas comment .

@FrankMittelbach C'est le cas : la question était je pense à \msg_log:nn , qui fait moins (pas) de formatage. On peut soutenir que nous pourrions supprimer \msg_log:nn et \msg_term:nn , car ils sont en réalité un peu entre le système de messagerie et le simple vidage de lignes dans le journal.

Deux questions distinctes se mélangent un peu ici.

• Messages formatés : actuellement, nous avons erreur/avertissement/info, avec le dernier
  n'apparaissant que dans le journal. @dbitouze demande un message d'information apparaissant sur le
  borne aussi. Peut-être pourra-t-il clarifier un cas concret où un tel message
  ne devrait pas être simplement un message d'avertissement ?

• Messages non formatés : \msg_ log:nn et \msg_ term:nn. je n'ai pas d'avis sur
  s'il faut les garder.

ok, je me suis évidemment trompé de bâton et j'ai mal lu la demande. Dans ce cas, je dirais qu'il ne devrait y avoir aucun changement dans le comportement normal du 2e (et le système de messagerie est pour le 2e même si nous sommes ici dans le repo expl3)

@dbitouze demande également qu'un message d'information apparaisse sur le terminal. Peut-être pourra-t-il clarifier un cas concret où un tel message ne devrait pas être simplement un message d'avertissement ?

Parfois, vous voulez informer l'utilisateur de quelque chose mais ne pas l'effrayer avec un avertissement.

Je suis d'accord avec cela - conceptuellement, je pense qu'il y a deux axes à ces messages : où ils apparaissent et à quel point ils sont graves.

Disons que j'ai une sortie de diagnostic (marginalement utile mais pas inutile) du traitement de certaines choses, et je l'envoie au fichier journal par défaut. L'afficher sur la console peut parfois être agréable (une option utilisateur "verbeuse"), mais il serait erroné d'appeler ces choses des avertissements.

J'appuie en quelque sorte cela, mais je ne pense pas que nous voulions vraiment un deuxième axe. les erreurs + avertissements doivent toujours être signalés à mon humble avis sur le terminal + journal, uniquement pour information, il semble qu'il y ait vraiment deux classes info (journal uniquement) et term-info.

Notez que le fait d'avoir des axes séparés aiderait beaucoup de toute façon, car nous ne voulons normalement pas que toutes les informations deviennent soudainement des informations sur les termes (ce que vous pourriez de toute façon en mappant les informations sur les informations sur les termes), mais généralement juste quelques informations pour toujours aller à la terminal donc j'envisagerais d'ajouter une autre catégorie terminfo et quelques \msg_terminfo:nn afin que vous puissiez clarifier vos intentions pour le comportement par défaut dans le code sans avoir besoin de le cacher quelque peu dans la configuration de msg .