Considering the following code snippet:

% \usepackage[T1]{fontenc}


\def\yy#1{inserted by yy -#1- inserted by yy}
\NewDocumentCommand{\zz}{m}{inserted by zz -#1- inserted by zz}


\edeftest{test - \yy{argument of yy}}\par
\edeftestii{test - \zz{argument of zz}}\par

\edeftest{test - \yy{argument of yy} - diacritics: á\'a - \robusttest}\par
\edeftestii{test - \zz{argument of zz} - diacritics: á\'a - \robusttest}\par


The first run of \edeftest writes the (my) expected behavior: \test macro is defined as test - inserted by yy -argument of yy- inserted by yy, as shown when \show\test is being executed. The first run of \edeftestii doesn't expands the \zz macro; I don't want that.

The second run of \edeftest and \edeftestii are worse. Both diacritics (á and \'a) were written to the \test and \testii macros (and to the txt file) with the TeX expanded semantic, i.e. \unhbox \voidb@x (...) \accent (...) unless we uncomment the T1 font encoding package at preamble, in which case, both accented "a" characters are in iso-8859-1 encoding not in UTF8, I guess because pdfLaTeX isn't an Unicode engine. Compiling with XeLaTeX and LuaLaTeX these characters are treated as UTF8 without issues: both macros and the .txt file contains áá. This is good for me but I would like a way to having this behavior compiling using pdfLaTeX.

Finally, in the second test set, the robust macro inserts the expected but undesired \protect primitive to the .txt file.

What I want? The ultimate goal is having a txt file whose contents is as closer as possible to the fully expanded macros \test and \testii or whatever argument the user inserts to the \edeftest macro. Closer as possible means closest to the text of the compiled document, so for example, some typographic change (\bfseries, \textbf, \fontsize) would be fine if were removed from the txt file. It is possible? I know when writing auxiliary files we have some limitations, that's why I emphasize the word "CLOSER".

How can \edeftest be defined to achieve that?

I know the trick \begingroup\edef{\endgroup but I could not use this here. Also some years ago I did ask a related question [1], it served for me on that scenario but here don't.

[1] Writing to a file - robust commands mess the text file written

  • How about \makeatletter \protected@write{\txt}{}{\testii} \makeatother? or \NewExpandableDocumentCommand{\zz}{...}... \zz isn't expandable as it is defined by you – user31729 Nov 16 '17 at 7:34
  • currently (this might change) characters are written out in their internal form (so á and \'a are written out as \'a if you use supported commands so not \edef and \write but \protected@edef and \protected@write. Your description isn't accurate: with [utf8] inputenc the characters won't be converted to latin1. But your requests are contradictory, you can fully expand everything but (in pdftex) á is two adjacent characters and macros combining those, converting to \'{a} and if typesetting to the glyph or \accent construct. To get á you want to suppress expansion. – David Carlisle Nov 16 '17 at 7:58
  • see egreg's answer to the question that you link to, as he says there you should not be using \write – David Carlisle Nov 16 '17 at 9:30
  • @DavidCarlisle and @ChristianHupfer, the \protected@write solution does not work for \zz. Both egreg's solutions does the same as here described: \zz is written unexpanded and \protect string is also written to the text file. Is that avoidable? (Assuming that \zz and \robusttest should remain as it are defined) – Emilio Lazo Nov 16 '17 at 15:11
  • that is what the protected commands do, prevent expansion. You could use xparse's ExpandableDocumentCommand declarations to define macros that disappear, but as I said above your intentions are not clear as the stated aims are in direct contradiction. You either need to suppress expansion if you want á written as á or if you want "full expansion" then you will get whatever á expands to. Either way, \edef and \write are not supported commands to apply to arbitrary sequences of latex commands. – David Carlisle Nov 16 '17 at 15:27

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.