Dear José, Thanks for your response.
On 2009-05-18 18:06, "José Matos" <jama...@fc.up.pt> wrote: > On Wednesday 13 May 2009 17:25:53 Gregory Jefferis wrote: >> BufferList::setCurrentAuthor >> >> Insisting that the current author have id 0. It turns out that BufferList::setCurrentAuthor is not really the issue. Rather it is because the default constructor for Changes includes an authorid of 0, therefore assuming that the relevant author list has the current author at position 0. There is no way for the Change object to know which AuthorList this author id points to, and trying to do this would generate some rather inefficient code. >> This means that diffing lyx files with tracked changes becomes a mess (I >> version control most of my lyx documents). > > I guess that do it in a proper way would require a file format change, and > this implies that such a change could only be allowed at the next stable > version (lyx 2.0). With that said I don't see any reason for us not to accept > this change. I see. Thank you for the encouragement. >> 1) Would it be possible to stop this resorting of the author list from >> happening? Perhaps by recording the current author id in the AuthorList >> rather than insisting that it must be 0 I think that the answer to my own question is that internally the current author must remain at position 0 for the AuthorList attached to the editing buffer. The AuthorList that actually gets read/written to the file could be ordered differently and have different ids - for example the hash value that I mentioned below. >> 2) more generally would there be something to be said for using a hash >> value (perhaps computed on author name+email) instead of a simple index for >> change tracking? That would make it possible to merge two versions of a >> document one of which contains changes from Andy and the other from Bert >> without having to rewrite all the author ids. > > If you have a patch implementing this behaviour and after some code revision I > expect it to be accepted. I say this because you have reviewed the code and > you seemed to have identified the relevant changes. Yes I have a patch (against branch as it happens, but I'm working with the git repo) that works fine, but I think it could be improved to make it more robust. I would happily post for comments. > In the case of a file format change this implies to write a plugin for lyx2lyx > (python code). It should not be difficult but, if necessary, either me or the Would you happen to be able to explain which direction(s) the required conversion has to work? My patch actually still allows old files to be read, but always saves with a hash value (ie new format). > others developers will provide the necessary feedback to attain you goal. Thank you very much. Greg.
