Dear Guillaume, dear developers,
On 2016-10-23, Guillaume Munch wrote:
> Le 23/10/2016 à 13:18, Guillaume Munch a écrit :
>> 1942c1942
...
resulted in a change in Math.lyx
...
>> < \textrm{created with \textbf{\textbackslash frac}} & &
>> \textrm{created with \textbf{\textbackslash cfrac}}\\
>> ---
>>> \textrm{created with \textbf{⧵frac}} & & \textrm{created with
>> \textbf{⧵cfrac}}\\
...
making it uncompilable.
> As I understand, Günter fixed this at 6ff89c4b9 (I missed it before,
> sorry). I am still curious for the questions below, if anybody knows.
In this case, it was an incomplete change to lib/unicodesymbols (more
details below).
The intermediate state was not "requiring a fileformat change" but
"buggy".
>> Also, and more importantly, this shows that some changes to
>> lib/[unicode]symbols are in fact file format changes. Is it expected in
>> this case? Is it easy to see which kind of changes to these files are
>> file-format-changing and which ones are not?
>From development.lyx:
Rule of thumb:
Whenever there is the danger that a previous version of LyX cannot
open a file using the new feature, a file format update is needed.
The file format change allows lyx2lyx rules to implement backwards
compatibility.
-> A changed (improved or even buggy) lib/unicodesymbols does not
require a file format change:
* lib/unicodesymbols is used on latex export and for relyxing,
changes will not prevent opening of LyX files.
* There is no safe way to backport improvements/changes via lyx2lyx.
(Converting a literal Unicode character to the correct LICR replacement
is ugly and has side effects (e.g. prevents the correct XHTML export.)
Improvements (additions, simple corrections) just let a literal Unicode
character work that previously did not work properly with 8-bit LaTeX.
For a new lyx version, this is normal and expected: not all improvements
can be backported.
I don't know whether this would be safe for stable, as some documents
that do work with the new revision fail with the old revision.
Günter
