For the past few days I've been working on the reusable functions for both parsing content of external files and writing external files. In the attached Leo document there are two new scripts. One is for generating the test data, and the other is for testing these two new functions. All tests are passing and round trip (*text-> outline -> text*) confirms that these functions have almost the same effect as Leo's FastAtFile reading and atFile writing methods.
Thinking about the format of external files and looking at them, I've come to the conclusion that this format contains some redundant information. This is not a big problem, but since I am currently working on this part of the Leo's code base, I wish to propose some improvements to this format. Having redundant information means that different files may produce the same outline. This can cause problems when testing round trip transformations. First of all I have to say, that I wrote two simple scripts that can automatically convert current external file content to the new format and back to the original format. - top level node gnx and its headline are not necessary. Both headline and gnx are present in the xml. They don't provide any useful information. This also can cause problems when two different outlines contain the same external file. If the top level node have different path or different gnx in those outlines than they would produce different file even if they have the same content. - *@+<<* sentinels are redundant too. When we encounter the node whose headline is a section reference, we know that the section reference was just before the opening node line. - *@-<<* sentinel and *@afterref* can be joined in one. The section name is not necessary because opening and closing sections must be properly nested. We know for sure that the closing section has the same headline as the last open one. The closing *@-<<* sentinel can give a clue whether the following line is *@afterref* or an ordinary line. For example *@-<<[* means same as closing section sentinel followed by an *@after* line, while* @-<<]* means there is no *@after *line after this closing sentinel. - *@+others* is not necessary because when we hit the first open node without the section reference in its headline we know for sure that just before this node was @others directive. Also when we encounter new open node with the different identation we can be sure that just before this node was *@others* directive. In the reading external file this line is used just to push current node data on the stack. But this signal can be added to the opening node sentinel as a single character. - format of *@+node* sentinel can be changed so that headline comes first and gnx and level at the end of the line for example: #@ at.findFilesToRead :ekr.20190108054317.1:6 instead of #@+node:ekr.20190108054317.1: *6* at.findFilesToRead It would be nicer to read source code using other editors - closing *@-leo* line is not necessary and there is no need for *@last* directives either. Last lines are just last lines of the top level node. - *@first* directive can be present in the body, but it doesn't need to be written in the external file, because we know that all lines coming before `*@+leo*` sentinel are first lines. Also so called "dangerous directives" (*@comment* and *@delims*), are never used in the Leo's code base. Personaly I can't think of the use case for those directives. If anyone knows for a specific use case where these directives can solve a real life problem which can't be solved without these directives, please share it here. I wish to understand why would anyone wish to use these directives. If no such use case can be found, I would strongly suggest dropping support for those dangerous directives. It would allow us to further simplify both reading and writing code. Less sentinel lines means less parsing less ambiguity and less work which leads to both simpler code and faster execution. Your thoughts, please. 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 leo-editor+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/0dda5ea8-b156-4ff6-a76e-5322894956f0o%40googlegroups.com.
issue-1598-experiments.leo
Description: Binary data
