Paul A. Rubin wrote:
> 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.
These mark a new paragraph. They are not inserted if you ommit a paragraph
break after the listings inset. So the lines are correct, AFAICS.
But I see now that the \endgroup tag indeed makes a difference.
> It seems to me that there has already
> been discussion elsewhere of situations in which LyX inserts unwanted
> blank lines.
This was something different (and is fixed in 1.6; I did not fix it in 1.5.x,
because it might have unwanted side effects)
> 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).
The problem is that the listings package cannot deal with unicode or any other
multibyte encoding (such as some CJK encodings); the listings parser simply
is not ready for that, and unfortunately, it's also not maintained currently.
Heiko Oberdiek has written a listingsutf8 extension package, but this only
fixes the encoding of lstinputlisting). So the reason for the brute-force
encoding switch is a fundamental limitation of the listings package.
However, I agree the encoding switch is a hack, and we should at least limit
the hack to the case where it is needed, i.e. only switch to latin1 if we
actually are in a multibyte encoding.
> So fundamentally, I think, it's a question of whether protecting the
> user from himself on the encoding issue is worth the price.
Suggestions are welcome. But they have to work in any encoding.
Jürgen
