On Saturday, June 6, 2020 at 9:30:38 AM UTC-4, vitalije wrote: > > 6. Changing Leo's file format to make your new code easier to test would >> be letting the tail wag the dog. I am confident that you can find a robust >> testing strategy that does not depend on a new file format. >> > > I understand your unease for making this kind of change. There is nothing > urgent in my proposition. If we change write code so that it outputs > starting sentinel *@+leo-ver=6*, we can use two different functions for > parsing the rest of the file content. Old files having *@+leo-ver=5* will > be loaded using the old reading code. So there won't be any inconveniences > for users, developers and future maintainers. >
I'm with Edward on this one. Having had corrupted or obsolete .leo files before, I do not want to have any possibility of having more. In addition, if a new version of Leo starts to write a new format for say @file nodes, those still using an older version will not be able to read them. It's already confusing enough to know what we are getting - what is the difference between @auto vs @file, for example? Adding a new format will add to the uncertainty, and if you call it something different like @file1, that would be even more confusing for a lot of people. Edward also mentioned redundancy. IMO, redundancy that helps in error recovery is good. Remember, there are going to be tens of thousands of files in the new format eventually. Some of them will have mis-used directives, some of them will have some kind of corruption. We need to have a good chance of recovering those files anyway. And we would still need to keep the old code for the old format in Leo for many years. So the result will be more complexity for Leo (both code branches will need to be maintained), not less, and more potential confusion for users and not less. If Leo had to read large files rapidly and repeatedly, the conclusion might be different. But why should I care if Leo could read leoref.leo in 20 ms less time? It wouldn't matter at all as a practical matter. As a technical matter, of course it's cool if you develop new, clean, fast code - who doesn't like that? But for Leo as an everyday tool, There's really no benefit that I can see. -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/6355bcc4-d57c-4e0f-ac81-962893538d8bo%40googlegroups.com.
