On Tue, Sep 13, 2022 at 6:23 PM spike <[email protected]> wrote:
We both have reasonable objectives. That's why I asked for an option > setting, so both use cases are covered, but I don't mind keeping a > private fork. > Leo is not going to change its file format. Not now. Not ever. There are two problems: 1. [Minor] Supporting two formats is messy within Leo. 2. [Fatal] Creating a new format now means that old versions of Leo won't be able to read .leo files created in the new format. Use a fork if you must. Leo isn't going to use UUIDs. Adding a command-line option is too horrible to contemplate. Adding a user setting won't work because user options are read too late. On that note I have some ideas for cleaning up and extending Leo's file > format and undo helpers -- user attribute handling in particular is > pretty cludgy -- but that would be for 7.0 at minimum. Such changes > would run far and deep and I've been trying to avoid that with my > submissions. > I will not consider such changes. Leo is a mature program, constrained by its past. Stability is much more important than behind-the-scenes improvements, or supposed improvements. Edward P.S. I did not sufficiently consider compatibility issues when approving PR #2818 <https://github.com/leo-editor/leo-editor/pull/2818>, which says: "Older versions of Leo will not be able to read files that use this feature. Files not using this feature are not affected." I'm considering whether to back out of this PR. Edward -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/CAMF8tS0B%2BQjq3H9GzriBkS1kEyMC%2B3kdZz_rhvZ0%3Df7DG_CSpQ%40mail.gmail.com.
