Jürgen Spitzmüller wrote:
Paul A. Rubin wrote:
I think it's a consequence of LyX setting the input encoding to latin1
(and surrounding the listing with \begingroup ... \endgroup).
No, without those, it shows exactly the same behaviour.
Not if you also take out the two blank lines that LyX inserts after
\endgroup.
Still, am I right that forcing latin1
in the listings environment means that you cannot in fact put, say, CJK
characters in a comment that escapes to LaTeX? Seems a bit restrictive.
Maybe you should open a bugzilla entry about this.
A bugzilla report does not strike me very sensible, since this is not a LyX
bug, but a listings bug/restriction.
The listings package does not require or force the \begingroup +
\inputencoding{latin1} + \endgroup commands, nor the two blank lines.
The blank lines are purely LyX. It seems to me that there has already
been discussion elsewhere of situations in which LyX inserts unwanted
blank lines. As far as the input encoding goes, my guess is that
whoever coded the listings support put this in to prevent the user from
accidentally blowing up the package by using a multibyte encoding.
However, as I mentioned above, the package specifically provides an
escape-to-LaTeX mechanism that allows the user to insert text from other
encodings. This presumably would be blocked by the current LyX
implementation (although I'm not the person to test this, since I'm
blissfully ignorant about non-Latin encodings).
One last thing. The listings package allows you to specify an escape
character that delimits strings that should be passed directly to LaTeX.
So, taking an excerpt from the .tex version of Álvaro's sample file,
...
\begin{lstlisting}[escapechar=`]
`\inputencoding{latin1}`
This is a lstlisting code added through an inset.
LyX surrounds this with\begingroup and\endgroup,
and creates a new paragraph after this one.
\end{lstlisting}
This is indented.\LyX{}-Code behaves differently than code listing
insets.Isn't this a contradiction to the User Guide?
...
seems to work. I can't test whether the encoding limitation is being
enforced, but the \inputencoding command is not printed in the listing,
and the following line is not indented. The problem with this approach
is that different users will want different escape characters.
So fundamentally, I think, it's a question of whether protecting the
user from himself on the encoding issue is worth the price.
/Paul
