On 20.07.08, Paul A. Rubin wrote:
Jürgen Spitzmüller wrote:
Anyway, I don't think you'll find a working example. As listings fails
with multibyte glyphs, it will also fail when multibyte glyphs are used
in ERT, no?
Not according to the documentation. You can define an escape to LaTeX
G. Milde wrote:
On 20.07.08, Paul A. Rubin wrote:
Jürgen Spitzmüller wrote:
Anyway, I don't think you'll find a working example. As listings fails
with multibyte glyphs, it will also fail when multibyte glyphs are used
in ERT, no?
Not according to the documentation. You can define an
Paul A. Rubin wrote:
I'm attaching a small proof-of-concept example that shows three things:
Let me rephrase that: once I wake up, I'll be attaching ...
listingsExample.lyx
Description: application/lyx
Paul A. Rubin wrote:
I'm attaching a small proof-of-concept example that shows three things:
Let me rephrase that: once I wake up, I'll be attaching ...
The example compiles fine in 1.6svn. It's probably too tricky to backport the
changes to 1.5.
Jürgen
Jürgen Spitzmüller wrote:
Paul A. Rubin wrote:
I'm attaching a small proof-of-concept example that shows three things:
Let me rephrase that: once I wake up, I'll be attaching ...
The example compiles fine in 1.6svn. It's probably too tricky to backport the
changes to 1.5.
No reason to
On 20.07.08, Paul A. Rubin wrote:
Jürgen Spitzmüller wrote:
Anyway, I don't think you'll find a working example. As listings fails
with multibyte glyphs, it will also fail when multibyte glyphs are used
in ERT, no?
Not according to the documentation. You can define an escape to LaTeX
G. Milde wrote:
On 20.07.08, Paul A. Rubin wrote:
Jürgen Spitzmüller wrote:
Anyway, I don't think you'll find a working example. As listings fails
with multibyte glyphs, it will also fail when multibyte glyphs are used
in ERT, no?
Not according to the documentation. You can define an
Paul A. Rubin wrote:
I'm attaching a small proof-of-concept example that shows three things:
Let me rephrase that: once I wake up, I'll be attaching ...
listingsExample.lyx
Description: application/lyx
Paul A. Rubin wrote:
I'm attaching a small proof-of-concept example that shows three things:
Let me rephrase that: once I wake up, I'll be attaching ...
The example compiles fine in 1.6svn. It's probably too tricky to backport the
changes to 1.5.
Jürgen
Jürgen Spitzmüller wrote:
Paul A. Rubin wrote:
I'm attaching a small proof-of-concept example that shows three things:
Let me rephrase that: once I wake up, I'll be attaching ...
The example compiles fine in 1.6svn. It's probably too tricky to backport the
changes to 1.5.
No reason to
On 20.07.08, Paul A. Rubin wrote:
> Jürgen Spitzmüller wrote:
>> Anyway, I don't think you'll find a working example. As listings fails
>> with multibyte glyphs, it will also fail when multibyte glyphs are used
>> in ERT, no?
> Not according to the documentation. You can define an "escape to
G. Milde wrote:
On 20.07.08, Paul A. Rubin wrote:
Jürgen Spitzmüller wrote:
Anyway, I don't think you'll find a working example. As listings fails
with multibyte glyphs, it will also fail when multibyte glyphs are used
in ERT, no?
Not according to the documentation. You can define an
Paul A. Rubin wrote:
I'm attaching a small proof-of-concept example that shows three things:
Let me rephrase that: once I wake up, I'll be attaching ...
listingsExample.lyx
Description: application/lyx
Paul A. Rubin wrote:
> > I'm attaching a small proof-of-concept example that shows three things:
>
> Let me rephrase that: once I wake up, I'll be attaching ...
The example compiles fine in 1.6svn. It's probably too tricky to backport the
changes to 1.5.
Jürgen
Jürgen Spitzmüller wrote:
Paul A. Rubin wrote:
I'm attaching a small proof-of-concept example that shows three things:
Let me rephrase that: once I wake up, I'll be attaching ...
The example compiles fine in 1.6svn. It's probably too tricky to backport the
changes to 1.5.
No reason to
Paul A. Rubin wrote:
If you mean an example for doing a listing in ERT, the OP (Álvaro) had
one in his original message. If you mean an example using multibyte
encoding,
Yes, I mean the latter.
I don't think so -- the closest I come to a foreign language
is some long-forgotten German,
Jürgen Spitzmüller wrote:
Anyway, I don't think you'll find a working example. As listings fails with
multibyte glyphs, it will also fail when multibyte glyphs are used in ERT,
no?
Not according to the documentation. You can define an escape to LaTeX
character, and anything bracketed by
Paul A. Rubin wrote:
If you mean an example for doing a listing in ERT, the OP (Álvaro) had
one in his original message. If you mean an example using multibyte
encoding,
Yes, I mean the latter.
I don't think so -- the closest I come to a foreign language
is some long-forgotten German,
Jürgen Spitzmüller wrote:
Anyway, I don't think you'll find a working example. As listings fails with
multibyte glyphs, it will also fail when multibyte glyphs are used in ERT,
no?
Not according to the documentation. You can define an escape to LaTeX
character, and anything bracketed by
Paul A. Rubin wrote:
> If you mean an example for doing a listing in ERT, the OP (Álvaro) had
> one in his original message. If you mean an example using multibyte
> encoding,
Yes, I mean the latter.
> I don't think so -- the closest I come to a "foreign" language
> is some long-forgotten
Jürgen Spitzmüller wrote:
Anyway, I don't think you'll find a working example. As listings fails with
multibyte glyphs, it will also fail when multibyte glyphs are used in ERT,
no?
Not according to the documentation. You can define an "escape to LaTeX"
character, and anything bracketed
Jürgen Spitzmüller wrote:
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
Paul A. Rubin wrote:
I saw the patch you proposed on the developer list, and I think it's a
reasonable compromise. The only limitation I can see is that users
writing in a language that needs multibyte encoding won't be able to
embed native language comments in a listing. If that's
Jürgen Spitzmüller wrote:
Paul A. Rubin wrote:
I saw the patch you proposed on the developer list, and I think it's a
reasonable compromise. The only limitation I can see is that users
writing in a language that needs multibyte encoding won't be able to
embed native language comments in a
Jürgen Spitzmüller wrote:
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
Paul A. Rubin wrote:
I saw the patch you proposed on the developer list, and I think it's a
reasonable compromise. The only limitation I can see is that users
writing in a language that needs multibyte encoding won't be able to
embed native language comments in a listing. If that's
Jürgen Spitzmüller wrote:
Paul A. Rubin wrote:
I saw the patch you proposed on the developer list, and I think it's a
reasonable compromise. The only limitation I can see is that users
writing in a language that needs multibyte encoding won't be able to
embed native language comments in a
Jürgen Spitzmüller wrote:
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
Paul A. Rubin wrote:
> I saw the patch you proposed on the developer list, and I think it's a
> reasonable compromise. The only limitation I can see is that users
> writing in a language that needs multibyte encoding won't be able to
> embed native language comments in a listing. If that's
Jürgen Spitzmüller wrote:
Paul A. Rubin wrote:
I saw the patch you proposed on the developer list, and I think it's a
reasonable compromise. The only limitation I can see is that users
writing in a language that needs multibyte encoding won't be able to
embed native language comments in a
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
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
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
Álvaro Manuel Recio Pérez wrote:
Program listing insets doesn't follow the same rules. Paragraphs after
listing insets are indented even if they are conceptually identical to
the LyX-Code environment. My questions are: Why does this happen? And,
is there a way to globally prevent the
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.
Still, am I right that forcing latin1
in the listings environment means that you
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
Álvaro Manuel Recio Pérez wrote:
Program listing insets doesn't follow the same rules. Paragraphs after
listing insets are indented even if they are conceptually identical to
the LyX-Code environment. My questions are: Why does this happen? And,
is there a way to globally prevent the
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.
Still, am I right that forcing latin1
in the listings environment means that you
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
Álvaro Manuel Recio Pérez wrote:
Program listing insets doesn't follow the same rules. Paragraphs after
listing insets are indented even if they are conceptually identical to
the LyX-Code environment. My questions are: Why does this happen? And,
is there a way to globally prevent the
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.
> Still, am I right that forcing latin1
> in the listings environment means that
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
Hello,
First of all, I'm still fairly new to Latex, so please excuse me if this
doesn't make sense. I'm using LyX to write a thesis with lots of
programming code snippets. I'm using indentation to separate paragraphs
and LyX correctly keeps the first paragraph after a title, an
enumeration,
Hello,
First of all, I'm still fairly new to Latex, so please excuse me if this
doesn't make sense. I'm using LyX to write a thesis with lots of
programming code snippets. I'm using indentation to separate paragraphs
and LyX correctly keeps the first paragraph after a title, an
enumeration,
Hello,
First of all, I'm still fairly new to Latex, so please excuse me if this
doesn't make sense. I'm using LyX to write a thesis with lots of
programming code snippets. I'm using indentation to separate paragraphs
and LyX correctly keeps the first paragraph after a title, an
enumeration,
45 matches
Mail list logo
