[EMAIL PROTECTED] wrote: > Hi Angus, > I am writing from here since I'm mute, > I can receive my email but not send it. > (the #$$%&** mail server is down) > > I don't understand your point regarding lyx2lyx. > > If I put all the needed functions in one place, > then I must do it for all the previous formats. What do > we gain with that? > > As we have now we only need to define the convertion > from one to the next and that is all. > > I though for some time about your remarks and I do not > see your point. Could you rephrase what you don't like with > the current approach and suggest a new one.
It's not that I don't like the current approach, but I don't see the point in retaining fine-grained control over the output. To my mind it is sufficient to output code suitable for the released versions of LyX. So, if (these formats are arbitrary. I don't know the actual numbers.): * LyX 1.1.6 supports format 210, * LyX 1.2.x supports format 215, * LyX 1.3.x supports format 221, * LyX 1.4.x (currently) supports 227, then it is sufficient to have lyxconvertfrom_210.py lyxconvertfrom_215.py lyxconvertfrom_221.py lyx2lyx can work out that it could generate output for formats 215 and 221 but would need one additional piece of info to generate output for format 227. Ditto, for lyxrevertfrom_227.py, lyxrevertfrom_221.py and lyxrevertfrom_215.py. lyx2lyx would need one additional piece of information to tell it that it can generate format 210 from lyxrevertfrom_215.py. The advantage of this scheme would be that each format change would not require a new lyxconvert_xyz.py file, yet files generated with recent cvs versions of LyX would continue to be upgraded. -- Angus
