> > 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 wrote this post not because I couldn't make tests. The attached Leo document contains scripts that do tests read and write functions performing a round trip on all external files found in the Leo installation folder. Each external file is read/parsed using a function *nodes_from_thin_file* which is a generator yielding tuples suitable to be piped into the *build_tree* which I wrote and tested earlier. The first testing part compares tuple values with the values found and prepared using normal Leo's read logic. Then test script actually builds a VNode instance representing the whole external file and uses function *v_to_string* to generate the content of the external file and compares the resulting content with the source file. 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. Explicit is better than implicit, I agree. Then why is the node level encoded using '*', '**', '*3*', '*4*', ...? Why is it better than just simple '1', '2', '3', ..? Isn't the second variant more explicit? The need for *@last* directive is a result of having *@-leo *sentinel. Try it yourself, delete the closing Leo sentinel and all `*@@last` *lines before it, and Leo will read this file correctly placing the last lines at the end of the node. The closing leo sentinel doesn't add any useful information to the reading process. But because it exists it generates a need for the at-last directives. Which means more code to execute, more regex searches to perform and no gains in return. If you edit external file and separate the opening *@+others* or *@+<< *sentinel from the following start node sentinel (for example insert a few lines between them), Leo will read this file correctly, but in the following write it will report file as being changed even if user didn't change anything. If those two sentinels are expressed *explicitly* not on their own separate line but in the following node start sentinel as a single character (for example "+/-" can represent the presence/absence of this directive), there won't be possible to separate those two sentinels and we would have two pattern less to match while reading. Even if you prefer user being able to better understand sentinels, having two consecutive lines containing the same *<<section name>> *text is not helping a lot. But it does cause user to see (and read) more garbage content. Perhaps we could have a new setting *@int default-external-file-format=5* by default and user can override it to 6 in myLeoSettings.leo. I am sure format-6 would be faster to read and write and some users would prefer to use it instead. Anyway, I won't insist on changing the format, but if we are changing something it would be better to make all changes at once. Regarding the first node start sentinel, perhaps new read code can just skip this sentinel and use the values from the xml for gnx and headline. When writing a file, Leo can check to see if this sentinel is present in the external file and if it is, it will keep this sentinel line unchanged. Leo always reads existing file to check whether there is a change or not, so this check won't be too expensive. This way single external file can be opened using different paths in different outlines without generating unnecessary file changes. Or we can just skip this sentinel when writing file. This will cause a single change to each external file, but after this no changes will ever be caused by accessing this file from different outlines. Vitalije -- 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/9ee3ffce-95ba-4fb4-9472-7589d61a4275o%40googlegroups.com.
