Listings : Can a keyword contain spaces?
Vicent Giner-Bosch
I am using the listings package for displaying some pseudocode.
I've defined some keywords via "morekeywords" and I've also tried to
add some keywords containing spaces via "otherkeywords", but I don't
get the desired output (keywords are defined to be in bolds, but the
ones containing spaces aren't shown in bolds).
Maybe I should use "alsoother" in order to make space be treated as an
"other"-class character, but I don't know if that could be dangerous
or could lead to any kind of problem within the package. I mean,
spaces are spaces. What can happen if within a lstlisting environment
they are no longer treated as spaces but as other kind of characters?
Any hint, tip or clue?
Thank you in advance.
--
vicent
Vicent Giner-Bosch
> Maybe I should use "alsoother" in order to make space be treated as an
> "other"-class character, but I don't know if that could be dangerous
> or could lead to any kind of problem within the package. I mean,
> spaces are spaces. What can happen if within a lstlisting environment
> they are no longer treated as spaces but as other kind of characters?
In fact, I've just tried with
alsodigit={ },% contains a space
and with
alsoother={ },% contains a space
but the result is the same.
To be more informative, I give here how I am defining my "pseudocode"
language:
\lstdefinelanguage{mylanguage}
{alsoother={ },%
morekeywords={recibe,devuelve,para,cada,en,hacer,desde,hasta,si,O,Y,NO,
%
entonces,fin,siguiente,es,vacío,verdadero,falso},%
otherkeywords={en otro caso,:,=},%
sensitive=true,%
morecomment=[l]{//},%
morecomment=[s]{/*}{*/},%
morestring=[b]",%
}
I want "en otro caso" to be a keyword in itself, as it is the
"official" translation of "otherwise" or "else" into Spanish, in a
programming language context.
That's my concrete case, so.
Looking forward to your answers,
--
vicent
GL
> On Apr 6, 7:15 pm, Vicent Giner-Bosch<vgi...@gmail.com> wrote:
>> Maybe I should use "alsoother" in order to make space be treated as an
>> "other"-class character, but I don't know if that could be dangerous
>> or could lead to any kind of problem within the package. I mean,
>> spaces are spaces. What can happen if within a lstlisting environment
>> they are no longer treated as spaces but as other kind of characters?
>
> In fact, I've just tried with
>
> alsodigit={ },% contains a space
>
> and with
>
> alsoother={ },% contains a space
>
> but the result is the same.
>
> To be more informative, I give here how I am defining my "pseudocode"
> language:
This is theoretically complex: a word has boundaries, listings looks for
the boundaries before checking against its lists.
The space is the natural boudary... with the line break
If you remove the space as word boundary, only the end of line remains,
and the word can be found if it is alone on its line. And any other
words won't be found...
\documentclass [a4paper,parskip]{article}\usepackage [T1]{fontenc}
\usepackage {etex,listings,xcolor}
\lstdefinelanguage{mylanguage}
{alsoother={ },
morekeywords={recibe,devuelve,para,cada,en,hacer,desde,hasta,si,O,Y,NO,%
entonces,fin,siguiente,es,vacío,verdadero,falso},%
otherkeywords={en otro caso,:,=},%
sensitive=true,%
morecomment=[l]{//},%
morecomment=[s]{/*}{*/},%
morestring=[b]",%
keywordstyle=[100]{\color{red}},
}
\lstset{language=mylanguage}
\begin{document}\makeatletter
\def\do #1{%
\def\lst@InitFinalize{\lst@Def {32}{\lst@ProcessLetter \space}}%
}\do{ }
\let\zap@@space \zap@space
\def\zap@space #1 \@empty{#1}
\lstset{morekeywords=[100]{word with spaces}}
\let\zap@space \zap@@space
{\loggingall
\begin{lstlisting}[alsoletter={ }]
word with spaces
\end{lstlisting}
}
\end{document}\endinput
Vicent Giner-Bosch
> This is theoretically complex: a word has boundaries, listings looks for
> the boundaries before checking against its lists.
>
> The space is the natural boudary... with the line break
>
> If you remove the space as word boundary, only the end of line remains,
> and the word can be found if it is alone on its line. And any other
> words won't be found...
>
Merci, GL. Thanks for your solution. :-)
So, I guess in this case the simplest way to proceed would be defining
"en", "otro" and "caso" as single keywords.
--
vicent
GL
simplest yes. I had a package in mind to compare tokens registers in a
more efficient and versatile manner than listings does.
The fact is always the same: pure basic TeX tools are very efficient
and usefull. But some poeple work on LaTeX 3 and some basic tools are
still missing...
So the not simplest but most efficient way would be to change the
implementation of the scanner in listings.sty. Everybody writes its
own scanner for its own purpose on its own package, but a general
scanner written in pure TeX with no \newtoks, no \newdimen, only
\countdef \toksdef etc. is missing...
> --
> vicent
Good evening
Rasmus Villemoes
> So, I guess in this case the simplest way to proceed would be defining
> "en", "otro" and "caso" as single keywords.
Or, if it some times would be wrong to highlight these, you could use
moredelim=[is][keywordstyle]||
and then write |en otro caso| (you can replace || by any pair of
characters which don't serve another purpose). Of course, this
requires a little explicit markup of the code, so if none of the words
constituting any of the compound keywords will ever be used alone,
your solution is better. Or, you could turn this technique around and
use |caso| with a suitable substitute for [keywordstyle] if "caso"
sometimes appears alone.
--
Rasmus Villemoes
<http://rasmusvillemoes.dk/>
Bruno Le Floch
> and usefull. But some poeple work on LaTeX 3 and some basic tools are
> still missing...
>
> So the not simplest but most efficient way would be to change the
> implementation of the scanner in listings.sty. Everybody writes its
> own scanner for its own purpose on its own package, but a general
> scanner written in pure TeX with no \newtoks, no \newdimen, only
> \countdef \toksdef etc. is missing...
Can you elaborate on what you think would be needed of such a scanner?
I've been thinking of writing one for a while, and any idea is
welcome :).
Bruno
GL
It's a too long issue to elaborate today... Sorry.
I already have a clean quick code, but it currently does not work with
braces (groups). The fact is that one could be able to make strings
substitutions in a series, very much quicker than with the code of
xstring. I found the point of interest because it's pure TeX
programming, without any support from any format.
I have to finish tabu package, and it does not require such a scanner,
hopefully ;-)
Ciao