LyX 2.0.8 Finally Read?

[Richard Heck]

What's the view about the status of lyx2lyx for 2.0.8? Did the last
round of changes take care of the issues we'd discovered, or is there
more work to do?

Richard

[Jürgen Spitzmüller]

What's the view about the status of lyx2lyx for 2.0.8? Did the last round
of changes take care of the issues we'd discovered, or is there more work
to do?

Beamer conversion is probably not yet completely sane. The problem here is
that every fix could break things elsewhere. A good test set (and multiple
testers) would be needed.

JÃŒrgen

Richard

[Scott Kostyshak]

Post by Jürgen Spitzmüller

What's the view about the status of lyx2lyx for 2.0.8? Did the last round
of changes take care of the issues we'd discovered, or is there more work to
do?

Beamer conversion is probably not yet completely sane. The problem here is
that every fix could break things elsewhere. A good test set (and multiple
testers) would be needed.

Indeed, examples/beamer.lyx roundtrip is broken for me. After the
roundtrip conversion I get the "Buffer... ended unexpectedly, which
means that it is probably corrupted" error. This was working a day or
two ago.

Scott

[Jürgen Spitzmüller]

Post by Scott Kostyshak
Indeed, examples/beamer.lyx roundtrip is broken for me. After the
roundtrip conversion I get the "Buffer... ended unexpectedly, which
means that it is probably corrupted" error. This was working a day or
two ago.

Try again. The file should at least open again now (I tried with the
complex beamerlyxexample1, which failed for me before).

The reason why it does not convert to a file that compiles without LaTeX
errors is that the frame arguments in the reverted documents use ERT for
the delimiters only (not for the arguments themselves), and we do not
support this in conversion (see FIXME in the convert_beamerframeargs
routine). I have started to work on this, but it is extremely complex.
Attached is a patch that sort of works _except_ for the case where
arguments are separated in two different ERTS, that is -- () means: in ERT:
(<)arg(>[)arg(])
works now, while
(<)arg(>)([)arg(])
does not yet. See attached patch. The crucial missing bit is the
ertcontdivline thing, which would need to take the above into account. But
I am running out of time.

JÃŒrgen

Post by Scott Kostyshak
Scott

[Scott Kostyshak]

Post by Scott Kostyshak
Indeed, examples/beamer.lyx roundtrip is broken for me. After the
roundtrip conversion I get the "Buffer... ended unexpectedly, which
means that it is probably corrupted" error. This was working a day or
two ago.

Try again. The file should at least open again now (I tried with the complex
beamerlyxexample1, which failed for me before).

As you describe, now I can open beamer.lyx after the round trip.

The reason why it does not convert to a file that compiles without LaTeX
errors is that the frame arguments in the reverted documents use ERT for the
delimiters only (not for the arguments themselves), and we do not support
this in conversion (see FIXME in the convert_beamerframeargs routine). I
have started to work on this, but it is extremely complex. Attached is a
patch that sort of works _except_ for the case where arguments are separated
(<)arg(>[)arg(])
works now, while
(<)arg(>)([)arg(])
does not yet. See attached patch. The crucial missing bit is the
ertcontdivline thing, which would need to take the above into account. But I
am running out of time.

This stuff sounds tricky and annoying. Thanks a lot for working on it!

Scott

[Georg Baum]

Post by Jürgen Spitzmüller

What's the view about the status of lyx2lyx for 2.0.8? Did the last round
of changes take care of the issues we'd discovered, or is there more work
to do?

Beamer conversion is probably not yet completely sane. The problem here is
that every fix could break things elsewhere. A good test set (and multiple
testers) would be needed.

Indeed. I believe that further development of the beamer conversion is not
possible without such a test set, and I don't see that coming very soon.

Therefore I'd suggest to release 2.0.8.1 now and put a note somewhere into
the announce,ent and/or release notes that there are known issues with
complex beamer documents. Apart from beamer I think the conversion is OK.


Georg

[Richard Heck]

Post by Georg Baum

Post by Jürgen Spitzmüller

What's the view about the status of lyx2lyx for 2.0.8? Did the last round
of changes take care of the issues we'd discovered, or is there more work
to do?

Beamer conversion is probably not yet completely sane. The problem here is
that every fix could break things elsewhere. A good test set (and multiple
testers) would be needed.

Indeed. I believe that further development of the beamer conversion is not
possible without such a test set, and I don't see that coming very soon.
Therefore I'd suggest to release 2.0.8.1 now and put a note somewhere into
the announce,ent and/or release notes that there are known issues with
complex beamer documents. Apart from beamer I think the conversion is OK.

I will follow this course.

Richard

[Pavel Sanda]

release notes that there are known issues with complex beamer documents.

I don't know whether you consider this document complex, but I still see the end_layout issue,
see attachment.

Pavel

[Georg Baum]

Post by Pavel Sanda

release notes that there are known issues with complex beamer documents.

I don't know whether you consider this document complex, but I still see
the end_layout issue, see attachment.

With this document I don't see an \end_layout problem, but a broken
\end_document if you run it htough lyx2lyx: It becomes \end_documen, and the
last line end is removed as well. This happens even for the no-op conversion
to format 474.

Something is really fishy here, but I don't understand what is wrong. Why is
the document corrupted even if you tell lyx2lyx to convert it to the version
it already has? This should not have anything to do with beamer, since the
beamer routines should not be called in this case.

Anyway, since nobody has time to have a deep look and set up a test suite, I
still think it is a good idea to do the final 2.0 release, and I also think
that the current warning is fine.


Georg

[Enrico Forestieri]

Post by Georg Baum

Post by Pavel Sanda

release notes that there are known issues with complex beamer documents.

I don't know whether you consider this document complex, but I still see
the end_layout issue, see attachment.

With this document I don't see an \end_layout problem, but a broken
\end_document if you run it htough lyx2lyx: It becomes \end_documen, and the
last line end is removed as well. This happens even for the no-op conversion
to format 474.

I actually don't see this. Looking at the converted file, I rather see
that an EndFrame layout gets wrongly nested as follows:

\begin_layout
\begin_inset Graphics
filename commit.png
height 80theight%

\end_inset


\begin_layout EndFrame <=
<= These lines should be after the next
\end_layout <= \end_layout tag
\end_layout

This smells like an off-by-one error, and indeed it is easy to spot it.
With the attached patch I can load the example document without warnings.

Post by Georg Baum
Something is really fishy here, but I don't understand what is wrong. Why is
the document corrupted even if you tell lyx2lyx to convert it to the version
it already has? This should not have anything to do with beamer, since the
beamer routines should not be called in this case.

As already said, I cannot reproduce this.

Post by Georg Baum
Anyway, since nobody has time to have a deep look and set up a test suite, I
still think it is a good idea to do the final 2.0 release, and I also think
that the current warning is fine.

Hmm...

[Pavel Sanda]

Post by Enrico Forestieri

Post by Georg Baum
Anyway, since nobody has time to have a deep look and set up a test suite, I
still think it is a good idea to do the final 2.0 release, and I also think
that the current warning is fine.

Hmm...

:))

[Enrico Forestieri]

Post by Enrico Forestieri
With the attached patch I can load the example document without warnings.

I have received no feedback and I am not a beamer expert, but the patch
looks correct to me, so I am going to commit it.

[Georg Baum]

Post by Enrico Forestieri

Post by Georg Baum
With this document I don't see an \end_layout problem, but a broken
\end_document if you run it htough lyx2lyx: It becomes \end_documen, and
the last line end is removed as well. This happens even for the no-op
conversion to format 474.

I actually don't see this. Looking at the converted file, I rather see

It seems that the \end_document problem shadowed the real one. With your fix
I can now convert the document correctly as well.

Post by Enrico Forestieri

Post by Georg Baum
Something is really fishy here, but I don't understand what is wrong. Why
is the document corrupted even if you tell lyx2lyx to convert it to the
version it already has? This should not have anything to do with beamer,
since the beamer routines should not be called in this case.

As already said, I cannot reproduce this.

I found the problem and fixed it at c75c6e44. For some reason the file which
I saved from the attachment did not have a trailing newline (maybe an off-
by-one error somewhere when the file length is determined;-), but lyx2lyx
assumed that all lines end with a newline. This assumption is not needed,
and I removed it.


Georg

[Enrico Forestieri]

Post by Georg Baum
I found the problem and fixed it at c75c6e44. For some reason the file which
I saved from the attachment did not have a trailing newline (maybe an off-
by-one error somewhere when the file length is determined;-), but lyx2lyx
assumed that all lines end with a newline. This assumption is not needed,
and I removed it.

However, note that, after your patch, if a line ends with '\r', it
is not stripped anymore. I think this may happen on Mac.

[Georg Baum]

Post by Enrico Forestieri
However, note that, after your patch, if a line ends with '\r', it
is not stripped anymore. I think this may happen on Mac.

Thanks for the hint, I was aware of \r as line end but then forgot to test
it. AFAIK, this is only used on pre-OS X macs, so not too important, but I
fixed in nevertheless.


Georg

[Scott Kostyshak]

What's the view about the status of lyx2lyx for 2.0.8? Did the last round of
changes take care of the issues we'd discovered, or is there more work to
do?

Do we care about Additional.lyx failing to export in a roundtrip with
format 413? lyx2lyx aptly warns
Warning: Lyx2lyx knows nothing about module 'multicol'. Please check
if short title insets have been converted correctly.
Warning: Lyx2lyx knows nothing about module 'shapepar'. Please check
if short title insets have been converted correctly.

but it warns on many other occasions that do not cause failure of exporting.

Scott