Re: [LyX/master] Work around bug #9841

[Richard Heck]

On 12/20/2015 01:45 PM, Guillaume Munch wrote:
>
> If what we need is a format change, then it is better to implement the
> solution n°3 (attached) described at
> .
> On the one hand, the format change is very simple. On the other hand, I
> do not like to suggest such a change at the last minute, and we should
> not do this if anybody has a doubt. I had been counting on a quick
> workaround such as dc016de3 to be available, as I was told. But, as I
> gathered from the conversation, the proposed change is the most
> consensual. It was favoured by Günter and Pavel, it is similar to what
> Jean-Marc suggested and also similar in LibreOffice to saving to the
> .fodt format.
>
> Notes:
> * The GUI can be updated later.
> * I do not update the documentation yet, but I checked that the update
> completes successfully.
> * I made sure that there is not minor difference between lyx, tex2lyx
> and lyx2lyx when writing the new parameter (it is always right before
> \origin).

No opinion on the substantive question.

Richard

Re: [LyX/master] Work around bug #9841

[Guillaume Munch]

Le 20/12/2015 10:16, Georg Baum a écrit :

I assume that the cited message was supposed to go to the list, so I
cite it completely.

Am 20.12.2015 um 05:20 schrieb Richard Heck:

On 12/19/2015 05:55 PM, Guillaume Munch wrote:

Le 19/12/2015 10:17, Georg Baum a écrit :

Unfortunately we have a regression now: Both tex2lyx and lyx2lyx output
these parameters in a different order than LyX.

In which sense is it a regression? Where is it important to have the
same order?

Having the same order avoids artificial changes if someone edits a
document produced by tex2lyx or lyx2lyx. This is mainly important for
documents under version control, and such a change could create a
similar merge conflict as the one which should be avoided by the changed
order. For the same reason all LyX files (docs, examples templates etc)
should be updated at once to the new format IMHO, so that we do not see
artificial changes as in b5c693eb0f99a.

Currently, both lyx2lyx and tex2lyx do not produce exactly the same
files as LyX (there are e.g. insignificant whitespace changes), but some
work has been done in the past to make the output as similar as
possible, and we should not throw away this work now by declaring that
we don't care anymore.


OK.




I assume Georg means that the tex2lyx tests will now fail, since there
will be
differences in the order in which these parameters are output. Of course
that can
be fixed by adapting the test files.


The tex2lyx tests do not fail currently, since the output order in
tex2lyx has not been changed. But you are right, if the order in tex2lyx
is changed, then the references must be updated, too.

Georg

Also, lyx2lyx might rely on the old order for backward conversion.
Did you check that it still works?

Yes, it does not depend on the order.

This is very difficult, maybe impossible, to know without tests...which
of course
we do not have.

It is a big problem with the lyx2lyx code, one I work hard to correct
along the way,
that people tend to make assumptions about the exact order in which
different lines will
appear, and even how many lines there are between different parameters.
As a result,
even the addition of blank lines where they shouldn't matter can break
lyx2lyx. And, in
the past, has. It isn't sufficient, therefore, to check places in which
output_changes and tracking_changes are actually mentioned in the
lyx2lyx code. Other code might assume
that the line that comes three lines after some other line is this or
that, and now it isn't.

Granted, code that makes such assumptions is inherently fragile and
should have been
written differently. But be that as it may, there's a lot of such code.

I think maybe what we need here is a format change, and lyx2lyx
reversion code that
ensures the old order. Then lyx2lyx code that assumes the old order will
still work.

I should have thought of both these things. At least the latter, since,
as I said, I've had
to deal with such bugs before, and they are not fun.



Thanks for the patient explanations. That starts making too much for a
quick workaround. I would suggest reverting dc016de3.

If what we need is a format change, then it is better to implement the
solution n°3 (attached) described at
.
On the one hand, the format change is very simple. On the other hand, I
do not like to suggest such a change at the last minute, and we should
not do this if anybody has a doubt. I had been counting on a quick
workaround such as dc016de3 to be available, as I was told. But, as I
gathered from the conversation, the proposed change is the most
consensual. It was favoured by Günter and Pavel, it is similar to what
Jean-Marc suggested and also similar in LibreOffice to saving to the
.fodt format.

Notes:
* The GUI can be updated later.
* I do not update the documentation yet, but I checked that the update
completes successfully.
* I made sure that there is not minor difference between lyx, tex2lyx
and lyx2lyx when writing the new parameter (it is always right before
\origin).


Guillaume

>From c25d226afe043ead37151e86b4eb0cf65b12e288 Mon Sep 17 00:00:00 2001
From: Guillaume Munch 
Date: Sun, 20 Dec 2015 13:08:49 +
Subject: [PATCH 1/3] Revert "Work around bug #9841"

This reverts commit dc016de34eab3fe24d9673a48cabf754bebbadaa.

See discussion at http://mid.gmane.org/n53ar8$1tj$1...@ger.gmane.org
---
 src/BufferParams.cpp | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/src/BufferParams.cpp b/src/BufferParams.cpp
index e3121c7..dfa13ec 100644
--- a/src/BufferParams.cpp
+++ b/src/BufferParams.cpp
@@ -1274,14 +1274,9 @@ void BufferParams::writeFile(ostream & os, Buffer const * buf) const
 	}
 
 	os << "\\tracking_changes " << convert(track_changes) << '\n'
+	   << "\\output_changes " << convert(output_changes) << '\n'
 	   << "\\html_math_output " << html_math_output << '\n'
 	   << "\\html_css_as_file " << html_css_as_file << '\n'
-		// \output_changes is outpu

Re: [LyX/master] Work around bug #9841

[Georg Baum]

I assume that the cited message was supposed to go to the list, so I 
cite it completely.


Am 20.12.2015 um 05:20 schrieb Richard Heck:

On 12/19/2015 05:55 PM, Guillaume Munch wrote:

Le 19/12/2015 10:17, Georg Baum a écrit :

Unfortunately we have a regression now: Both tex2lyx and lyx2lyx output
these parameters in a different order than LyX.

In which sense is it a regression? Where is it important to have the
same order?
Having the same order avoids artificial changes if someone edits a 
document produced by tex2lyx or lyx2lyx. This is mainly important for 
documents under version control, and such a change could create a 
similar merge conflict as the one which should be avoided by the changed 
order. For the same reason all LyX files (docs, examples templates etc) 
should be updated at once to the new format IMHO, so that we do not see 
artificial changes as in b5c693eb0f99a.


Currently, both lyx2lyx and tex2lyx do not produce exactly the same 
files as LyX (there are e.g. insignificant whitespace changes), but some 
work has been done in the past to make the output as similar as 
possible, and we should not throw away this work now by declaring that 
we don't care anymore.



I assume Georg means that the tex2lyx tests will now fail, since there
will be
differences in the order in which these parameters are output. Of course
that can
be fixed by adapting the test files.


The tex2lyx tests do not fail currently, since the output order in 
tex2lyx has not been changed. But you are right, if the order in tex2lyx 
is changed, then the references must be updated, too.


Georg

Also, lyx2lyx might rely on the old order for backward conversion.
Did you check that it still works?

Yes, it does not depend on the order.

This is very difficult, maybe impossible, to know without tests...which
of course
we do not have.

It is a big problem with the lyx2lyx code, one I work hard to correct
along the way,
that people tend to make assumptions about the exact order in which
different lines will
appear, and even how many lines there are between different parameters.
As a result,
even the addition of blank lines where they shouldn't matter can break
lyx2lyx. And, in
the past, has. It isn't sufficient, therefore, to check places in which
output_changes and tracking_changes are actually mentioned in the
lyx2lyx code. Other code might assume
that the line that comes three lines after some other line is this or
that, and now it isn't.

Granted, code that makes such assumptions is inherently fragile and
should have been
written differently. But be that as it may, there's a lot of such code.

I think maybe what we need here is a format change, and lyx2lyx
reversion code that
ensures the old order. Then lyx2lyx code that assumes the old order will
still work.

I should have thought of both these things. At least the latter, since,
as I said, I've had
to deal with such bugs before, and they are not fun.

Richard

Re: [LyX/master] Work around bug #9841

[Guillaume Munch]

Le 19/12/2015 10:17, Georg Baum a écrit :

Guillaume Munch wrote:


commit dc016de34eab3fe24d9673a48cabf754bebbadaa
Author: Guillaume Munch 
Date:   Thu Dec 17 01:04:25 2015 +

 Work around bug #9841

 \output_changes is now output at a distance from \tracking_changes.

 Since both parameters can be seen as per-user preferences, they can
 cause undesirable merge conflicts, in a multi-author setting, were it
 treated as a single block by the version control system, as was the
 case before this patch.



Unfortunately we have a regression now: Both tex2lyx and lyx2lyx output
these parameters in a different order than LyX.


In which sense is it a regression? Where is it important to have the 
same order?



Also, lyx2lyx might rely on
the old order for backward conversion. Did you check that it still works?


Yes, it does not depend on the order.


Guillaume

Re: [LyX/master] Work around bug #9841

[Georg Baum]

Guillaume Munch wrote:

> commit dc016de34eab3fe24d9673a48cabf754bebbadaa
> Author: Guillaume Munch 
> Date:   Thu Dec 17 01:04:25 2015 +
> 
> Work around bug #9841
> 
> \output_changes is now output at a distance from \tracking_changes.
> 
> Since both parameters can be seen as per-user preferences, they can
> cause undesirable merge conflicts, in a multi-author setting, were it
> treated as a single block by the version control system, as was the
> case before this patch.
> 

Unfortunately we have a regression now: Both tex2lyx and lyx2lyx output 
these parameters in a different order than LyX. Also, lyx2lyx might rely on 
the old order for backward conversion. Did you check that it still works?


Georg