argument of type v errors if the argument contains a tab

[u-fischer]

The following document which contains a tabulator (09) errors:

\documentclass{article}
\begin{document}
\NewDocumentCommand { \myverb } { v  }{}

\myverb|a  	 b|
\end{document}

errors with

! LaTeX3 Error: The verbatim command '\myverb' cannot be used inside an
(LaTeX3)        argument.

For immediate help type H <return>.
 ...                                              
                                                  
l.15 \myverb{a  	
                  b}
? 

[PhelypeOleinik]

A tab is usually catcode 10, and space tokens are used to indicate premature tokenisation of the argument, thus the error. Adding a tab to \dospecials makes the error go away:

\documentclass{article}
\begin{document}
\ExplSyntaxOn
\tl_gput_right:Nn \dospecials { \do \^^I }
\ExplSyntaxOff
\NewDocumentCommand { \myverb } { v } { #1 }

\myverb|a 	 b|
\end{document}

but then you get a Ψ b in the typeset output. One option would be to make \^^I active and make it expand to a space. But perhaps it should be left as it is (without the error, I mean) and let the macro writer decide what to do with tabs: sometimes one wants to make it a space, and sometimes it should be a tab indeed. Seems like the solution to this issue will be the same as for #756...

[blefloch]

I wrongly replied to another thread with a curious example: Interestingly \verb*|Y Z| (with two consecutive tabs) gives a single space because \verb changes the catcode of space but not of tab. It is more convenient for macro writers if we make some characters active, but we have to carefully choose which ones because every active character requires a definition.

[pablgonz]

Just as a comment, some time ago I came across this Keyboard TAB character in argument v (xparse)
. I didn't report it because the explanation given by (@Ulrich-Diez), might be a good idea to document the behavior of TAB in xparse.

[blefloch]

Somewhat-breaking-change idea for the catcode regime that xparse's v-type argument should use: - maybe set catcodes to those valid in the main part of the document (\c_document_cctab?), or maybe use the current catcodes, then - loop over chars 0-127, and if the catcode is not 11 (letter) or 12 (other), make it 13 (active). In particular, space and tab would end up active, as well as all special characters such as %, $, ^, ~, &, ^^M, ^^J, ^^@ etc, and babel shorthand characters. In pdftex with inputenc the 128-255 range would stay active. Also provide a "w" argument used as "w{\act}" which would pass to \somemacro each active character mentioned above, yielding as the argument #1 the expansion of (for instance) Hello\act{ }world!\act{^^I}I\act{^^a0}am.

[Ulrich-Diez]

Sent: Thu, 02 Jul 2020 12:54:16 -0700 By: "Bruno Le Floch" <notifications@github.com> To: "latex3/latex3" <latex3@noreply.github.com> Cc: "Ulrich-Diez" <eu_angelion@web.de>, "Mention" <mention@noreply.github.com> Subject: Re: [latex3/latex3] argument of type v errors if the argument contains a tab (#762)  

Somewhat-breaking-change idea for the catcode regime that xparse's v-type argument should use: - maybe set catcodes to those valid in the main part of the document (\c_document_cctab?), or maybe use the current catcodes, then - loop over chars 0-127, and if the catcode is not 11 (letter) or 12 (other), make it 13 (active). In particular, space and tab would end up active, as well as all special characters such as %, $, ^, ~, &, ^^M, ^^J, ^^@ etc, and babel shorthand characters. In pdftex with inputenc the 128-255 range would stay active. Also provide a "w" argument used as "w{\act}" which would pass to \somemacro each active character mentioned above, yielding as the argument #1 the expansion of (for instance) Hello\act{ }world!\act{^^I}I\act{^^a0}am. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub[#762 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AJ5K4ONCOCVMA6VGRZXDMEDRZTQWRANCNFSM4OKUWAIQ].

v-type-arguments can be used for different purposes. E.g., they can be used in situations where things shall go into the .pdf-output-file for being displayed "as is" (probably in some typewriter-font/monospaced-font/ fixed-pitch font) by the pdf-viewing-application. But I often see v-type-arguments used when it is intended to "copy" a snippet of .tex-input to an external text-file "as is": The snippet of .tex-input is read and tokenized as a v-type-argument, then the v-type-argument gets written to external file via \addtocontents or \immediate\write or whatever. Be aware that many characters will be active by default when using the inputenc-package on 8-bit-engines for processing utf8-encoded .tex-input-files. This causes trouble when it comes to writing "as is" a v-type- argument to external text-file because these active characters get expanded instead of being written "as is" when writing takes place. As a workaround \detokenize can be applied at writing-time/ expansion-time, ensuring that expandable active characters will be turned into non-expandable characters of category code 12(other). Probably in the documentation of xparse's argument-type "v" it should be mentioned that precautions should be taken depending on what is to be done with the tokens of the v-type-argument (processing things that are to end up in the .pdf-output-file/processing things that are to be written to external text file or console). Another issue: With v-type-arguments the surrounding verbatim-delimiters get stripped off. This is a good thing in normal circumstances. But if you wish to make the v-type-argument a moving argument, i.e., an argument that gets written to an external text file which in the next LaTeX-run will be read and processed, you may wish to keep the verbatim- delimiter. E.g., I needed something like the \addtocontents- \@writefile-mechanism suitable for verbatim-material. So my \addtocontents-pendant did apply \detokenize to a v-type-argument before writing it to the .aux-file, preceded by my \@writefile-pendant (which would also process a v-type-argument) and surrounded by the verbatim-delimiter in use when the \addtocontents-pendant grabbed its argument. I think an argument-type similar to the v-type would be nice which would not strip off the verbatim-delimiter: The verbatim-argument can easily be "moved" to other text-files and be processed by other argument-of-v-type-processing macros when it comes to inputting/processing these other text-files. Sincerely Ulrich

[car222222]

Lots of ideas here, @Ulrich-Diez.

There are indeed many types and uses of so-called ‘verbatim in TeX’, all with somewhat or very different requirements.