Latex3: \msg_term messages don't tell where they are coming from

I'm not super familiar with l3msg, but I think that this is by design. If you want an "Info" message it can be obtained using \msg_info:nn (but then it goes to the log).

\msg_info:nn (but then it goes to the log).

That's the point: AFAICT, it is rather common to see in the terminal some Info messages which are perfectly identifiable.

The design decision here was that most messages are error/warning/info, and should go to both the terminal and the log. The two 'lower level' functions, \msg_term:nn and \msg_log:nn, are pretty specialised and meant to be 'not noisy'.

most messages are error/warning/info, and should go to both the terminal and the log.

But precisely, info messages go only to the log:

\msg_info:nnnnnn {⟨module ⟩} {⟨message ⟩} {⟨arg one ⟩} {⟨arg two ⟩} {⟨arg three ⟩} {⟨arg four ⟩}

Issues ⟨module⟩ information ⟨message⟩, passing ⟨arg one⟩ to ⟨arg four⟩ to the text-creating
functions. The information text is added to the log file.

@dbitouze Ah, sorry, yes: info is just in the log as you say. The aim with the 'raw' messages was they are more likely to be very low level stuff where additional 'noise' isn't required. To be honest we've not really seen them used much 'in the wild' - I guess what I wonder about with hindsight is use cases. (For really low level stuff, I'd use \iow_log:n/\iow_term:n anyway.)

@josephwright I tend to agree that "info" should be have like "warning" with the difference that it doesn't show on the terminal but not that it logs the stuff differently. For example, warnings are usually formatted with exlicit linebreaks based on the idea that there is some "(module)" prefix on following lines and when I change a group from warning to info I think all that should change is where it shows up not how.

@FrankMittelbach That is the case: the question was I think about \msg_log:nn, which does less (no) formatting. Arguably we could drop \msg_log:nn and \msg_term:nn, as really they are somewhat in between the message system and simply dumping lines to the log.

Two separate questions are getting a bit mixed up here.

• Formatted messages: currently we have error/warning/info, with the last one
  only appearing in the log. @dbitouze asks for an info message appearing on the
  terminal as well. Maybe he can clarify a concrete case where such a message
  should not simply be a warning message?

• Unformatted messages: \msg_log:nn and \msg_term:nn. I have no opinion on
  whether to keep them.

ok, I obviously got the wrong end of the stick and read the request incorrectly. In that case I would say there should be no change in the normal 2e behavior (and the messaging system is for 2e even if we are here in expl3 repo)

@dbitouze asks for an info message appearing on the terminal as well. Maybe he can clarify a concrete case where such a message should not simply be a warning message?

Sometimes you want to inform the user about something but not scare him with a warning.

I agree with this — conceptually I think there are two axes to these messages: where they appear, and how severe they are.

Let’s say I have some diagnostic (marginally useful but not useless) output from processing some stuff, and I send it to the log file by default. Showing it on the console might be nice sometimes (a “verbose” user option) but it would be wrong to call these things warnings.

I sort of second that but I don't think we really want a second axis. errors + warnings should always be reported imho on the terminal + log ,only for info it seems there are really two classes info (log only) and term-info.

Note that having separate axes would help so much anyway, because we normally don't want all infos to suddenly become term-infos (which you could anyway by mapping info to term-info) but typically just some infos to also always go to the terminal so I would consider adding a further category terminfo and some corresponding \msg_terminfo:nn so that you can make your intentions for the default behavior clear in the code without the need to set that somewhat hidden in msg setup.