# Custom verbatim that sets all spaces (“ ”) as visible spaces (“␣”) that can line-break

It makes sense to typeset code in a monospaced font. Sometimes such code needs to be embedded in a paragraph context, and then it will be useful to allow it to linebreak. In order to visualize spaces properly, I would like a macro \code that typesets its argument with all spaces replaced by visible spaces that can line-break (on both sides). For example, it'd typeset

\code{string with  spaces}


as string␣with␣␣spaces where each ␣ can linebreak on either side. As my question is about code that is to be embedded in paragraph text, we can assume that the argument to such a \code macro won't contain any paragraph breaks.

Actually my use case is more specific. I typeset string constants using the macro \strC shown below. This might still be interesting to others, as it is a bit more than just a variation on \verb, with the custom \textsl potentially complicating the solution.

I presently use an explicit call to a macro \vsp (simply defined as \allowbreak\textvisiblespace\allowbreak; both \allowbreaks are needed) as a workaround, but it would be nice to be able to just type (one or more) spaces inside the macro argument.

\documentclass{article}

\newcommand*{\strC}[1]{\textnormal{\textsl{\texttt{#1}}'}} % string constant
\newcommand*{\vsp}{\allowbreak\textvisiblespace\allowbreak} % visible space

\begin{document}

\hspace*{31em}\strC{hello world}
% linebreaks as:  ‘hello / world’    (space disappears)

\hspace*{31em}\strC{hello\textvisiblespace{}world}
% linebreaks as:  ‘hello␣world’ / ∅  (no linebreak)

\hspace*{31em}\strC{hello\vsp{}world}
% linebreaks as:  ‘hello / ␣world’   (as intended; a linebreak after ␣ would also be ok)

\end{document}


For this code specifically the idea would be to type \strC{hello world} but to get the same result as with \strC{hello\vsp{}world}. Multiple typed spaces should yield multiple ␣-characters; a string ␣␣␣␣␣ may break anywhere (beginning, anywhere in the middle, end).

Here is a related question also asking about functional conversion of input (in this case for the specific purpose of pasting).

Summary of answers: Both answers are very good, and the comment pair (just below) by user cacamailg is very good too, but no solution as of the time of this edit is perfect. For now I'll stick with my manual \vsp macro, which is quick to type and gives me full control. If someone has a refinement of one of the three approaches that is flawless, I'll accept that as the answer.

• The package listings has the \lstinline for inline and lstlisting environment. With the options: \lstset{breaklines=true,showspaces=true} probably does what you want. – cacamailg Apr 23 '13 at 12:28
• @cacamailg Except for the styling of the font, it does! I haven't tried the customization options of listings, which might help with that. – Lover of Structure Apr 23 '13 at 21:59

You have to change the meaning of the active space. (Of course this means that \code cannot be in the argument to another command (see below*), though careful usage of \scantokens might help.)

\documentclass{article}

\newcommand*{\strC}{\begingroup
\obeyspaces
\begingroup\lccode~=\ %
\lowercase{\endgroup\let~}\vsp
\dostrC}
\newcommand{\dostrC}[1]{\textnormal{{\slshape\ttfamily#1}'}\endgroup} % string constant
\newcommand*{\vsp}{\allowbreak\textvisiblespace\allowbreak} % visible space

\begin{document}

\hspace*{31em}\strC{hello world  x   y}

\end{document}


*For example, if we wrap the command into a macro \ident that doesn't modify its argument (\newcommand*{\ident}[1]{#1}), the result of

\ident{\strC{hello world  x   y}}


turns out to be as if we had used the original \strC macro without any explicit visible spaces: all space sequences will be shrunk to an ordinary (i.e., line-breaking and disappearing ("soft")) space.

• @LoverofStructure If you add \scantokens{ before \textnormal and \noexpand} before the closing quote, you can use \strC in the argument to another command; but you can't get multiple spaces, because they are converted to single space tokens during tokenization and this can't be reverted. – egreg Apr 23 '13 at 22:34

[EDITED to address multi-softspace issue] The stringstrings package might apply here, with a caveat. Since stringstrings is not a verbatim like string processor, multiple spaces in an argument are otherwise interpreted by LaTeX as a single space token, unless you explicitly put hard spaces (~ characters) to represent multiple spaces. So I tried a \catcode redefinition to try to overcome that limitation. As long as the \strC invocation doesn't follow the starred version of \hspace, it seems to work (not sure what is peculiar to the star version, but in that situation, multi-softspaces are interpreted as a single softspace). Thus, with that exception noted, stringstrings can parse the string, converting spaces and tildes, each into a visible space character, allowing line breaks.

\documentclass{article}
\usepackage{stringstrings}

\newcommand*{\strC}[1]{%
\catcode\ =12%
\strCB{#1}%
\catcode\ =13%
}

\newcommand*{\strCB}[1]{%
\encodetoken[1]{\textvisiblespace}%
\encodetoken[2]{\allowbreak}%
\convertchar[e]{#1}{ }{\allowbreak\textvisiblespace\allowbreak}%
\convertchar[e]{\thestring}{~}{\allowbreak\textvisiblespace\allowbreak}%
\retokenize{\thestring}%
\textnormal{\textsl{\texttt{\thestring}}'}%
\decodetoken[1]{\textvisiblespace}%
\decodetoken[2]{\allowbreak}%
} % string constant

\begin{document}

The hspace* affects the bevavior of the subsequent strC (not sure why).

\hspace*{31em}\strC{hello world.  This is a ~ Big   test}

But in other cases, multiple softspaces are correctly interpreted:

\strC{Hello   World}

\strC{hello world.  This is a ~ Big   test}

\hspace{31em}\strC{hello world.  This is a ~ Big   test}

\end{document}


I would add some final disclaimers: stringstrings is slow, which can be a problem for large manipulations; stringstrings isn't made to easily handle the \` backslash character. This isn't a problem if the code you are typesetting is a language that doesn't use the backslash character, but will obviously be so if you are typesetting LaTeX code.