8

I want spaced keywords in listings (that is, keyword, with spaces in between).

Now, there are some questions in this site already answered, like this one, where the official answer is that “it is not possible”. But, of course, like almost everything, there are workarounds that let you do it.

However, I've seen in the documentation of microtype correctly highlighted keywords that do contain spaces (e.g., no ligatures, outer kerning, outer spacing).

That's all. If I didn't make myself clear, please, leave a comment. That's the question: I want to reproduce the system used in microtype's documentation.


Update

As @Robert noted, he used latin1 encoding in the documentation. Which seems to work nice with lstlisting (apart from non-breaking spaces, it even accepts, e.g., á, ü by default). But I use utf8 (not for anything special, but because it's recommended everywhere), which doesn't behaves well with listings. Since I like this idea of using non-breaking spaces to define keywords with spaces, I will rewrite my question

Is there a way to teach utf8/listings to understand non-breaking spaces inside of keywords?

Here is a minimal non-working example:

NOTE: the space between spaced and keyword is a non-breaking space (as you can see in the image below).

\documentclass{scrartcl}

%\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenx} % With latin1 it works perfectly

\usepackage{listings}
\lstset{keywords={spaced keyword}, columns=fullflexible}

\begin{document}
\begin{lstlisting}
  notakeyword spaced keyword notakeyword
\end{lstlisting}
\end{document}

enter image description here

  • 1
    The premise of your question is wrong: the file used to generate the microtype manual (microtype.dtx) doesn't use listings at all for typesetting "outer spacing", "outer kerning", "no ligatures" as shown on p17 of that manual. Instead, this is done via a macro called \key defined with \DeclareRobustCommand\key[1]{\textcolor{thered}{\ttfamily#1}} in microtype.dtx. No non-breaking space is involved or necessary for that. – jub0bs Jun 16 '14 at 17:38
  • 2
    Now I see what you mean. I think I was looking at the wrong page of the manual. For information, TeX.SX "sanitizes" the text you paste in the answer box; for instance, tabs get converted to 4 spaces. I didn't know it also converts non-breaking spaces to spaces. – jub0bs Jun 16 '14 at 19:09
  • 2
    You need to load inputenc with an encoding that (1) contains the non-breaking space and (2) is not utf8 because listings won't like it. (microtype.dtx uses latin1). – Robert Jun 17 '14 at 23:53
  • 1
    @Robert Well, that's an answer ;) I totally missed that. However, everywhere you look utf8 is recommended (and that's the only reason I use it). (1) Is it possible to teach the non-breaking space to utf8? (2) Is there a workaround so that utf8 won't collide with listings? You can post an answer, but I will wait a little more to see if someone offers a solution. – Manuel Jun 18 '14 at 8:49
  • 1
    @Manuel Yes, you can use linstings plus UTF8. See tex.stackexchange.com/questions/176694/… including my first comment about LaTeX usage of encTeX. – wipet Aug 7 '14 at 2:47
1

Well, most of your questions have already been answered either in the question itself or in the comments, so here's just a recap to satisfy the site's mores:

  • The workaround to allow spaces in keywords that microtype.dtx employs is to use the "non-breaking space" in lieu of a normal space to make listings believe that it's a letter, while it will be output as a space;
  • this requires loading an input encoding that does indeed contain the non-breaking space and maps it to a normal space (e.g., latin1).
  • The problem in your example is that you use utf8 input encoding, which – though it meets the above requirement – is not compatible with the listings package. I don't see a way to fix this incompatibility other than in listings itself.

AFAICT, you only have two options:

  • either don't use utf8 encoding – which in your case appears to be possible considering the fact that you say the only reason why you use it in the first place is that it is recommended everywhere;
  • or use the listingsutf8 package (which understands utf8 input in included files) and store all your code listings in separate files – maybe a bit cumbersome depending on the number of listings you have.

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.