As illustrated in the MWE, using \tex_par:D rather than \par within a list environment leads to unexpected side-effects. Is this intended behavior? If so, it's likely to break a lot of code. I ran across this issue trying to use the current version of lipsum, which uses the expl3 version, within KOMA-Script's addmargin environment, and any other environment that uses the same list trick is going to be broken in this case.

\NewDocumentCommand{\mypar} {} {\tex_par:D}

 \item Here's a paragraph with enough text that we can see where the line wraps.

 Here's another paragraph after a traditional paragraph break. This is fine.

 Now we'll end this one with the expl3 version to see what happens next.\mypar
 And here's a forth to see where we are. The left and right margins are now disregarded.\par

 And they don't come back.

Resulting in this output:

enter image description here

  • Doesn't par has a special meaning inside lists? Thus the inserted mypar is different from the normal par inside lists. – daleif Dec 25 '18 at 1:23
  • 1
    Yes, \list calls \@trivlist which uses \@setpar to redefine \par. The definition of \mypar or \tex_par:D is never changed, though, thus the different results – siracusa Dec 25 '18 at 1:35
  • OK, so now I understand why it's happening. I'm still curious as to whether this is an intentional design decision. The interface3 documentation urges us to avoid calling primitives directly, but this sort of issue suggests we can't safely do that because we can't predict the interactions (like lipsum + addmargin) that users will create, which can mean expl3 code gets called in contexts where the :D instructions don't have the meaning they should. – Karl Hagen Dec 25 '18 at 2:03
  • 1
    \cs_new:Npn \latex_par: { \par } – Henri Menke Dec 25 '18 at 7:32
  • @HenriMenke Ah yes, you are right. – TeXnician Dec 25 '18 at 10:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.