Ordinary spaces would be welcome to not be ignored in some places

[dbitouze]

The \ExplSyntaxOn function switches to a category code regime in which spaces and new lines are ignored, [...] Within this environment, ~ is used to input a space.

Couldn't this be disabled in places where ordinary spaces have no chance to be spurious, such as in ⟨text⟩ arguments of \msg_new:?

[davidcarlisle]

This can't be done really. It would make \msg_.... be like \verb and only fully work at the top level and not in the argument of another command. Messages are almost always in conditionals or definitions, and so the spaces are already gone while parsing the outer command before the message command is interpreted at all. (Noted that I was thinking about the message here rather than the definition, but still...

[u-fischer]

well the definition of messages where the text is setup are typically at package level. So it probably be done, but I'm not sure if it is worth it, the text are normally short anyway.

[blefloch]

Workaround since message definitions are global. One should make sure not to put spaces at the start or end of the message. I'm not sure here if I need to also mess with the \endlinechar.

\group_begin:
\char_set_catcode_space:n { `\ }
\msg_new:nnn {mypkg} {mymsg}
  {Some message text using '#1' and usual message shorthands \{ \ \ \}.}
\msg_new:nnn {mypkg} {mymsg2}
  {% <========================= careful about spurious spaces! 
    Another message\\%
    \iow_indent:n {something}.%
  }
\group_end:

[josephwright]

We did have different handling of spaces in the past for messages, but we then get into real issue with documenting what we support.

[FrankMittelbach]

I'm against making an exception here, it just means that it would work on top-level but not inside any command (just like verb as @davidcarlisle pointed out. Granted that most of the time it will be on top-level when declaring messages, it is not impossible to have them inline. So I think the current approach of always requiring to use ~ for textual strings is good and simple and we should stick to it.

[blefloch]

I agree with Frank. But I think we should document my workaround in the documentation of \msg_new:nnnn for those who wish: this is not the first time the question has been asked.

[FrankMittelbach]

@blefloch If we do that then perhaps something like \ExplSyntaxSpaceNormal ... \ExplSytnaxSpaceIgnored (or some better name) is nicer than this workaround adn then 2 pages later \group_end. Just thinking out loud.