On Wednesday, April 2, 2025 at 1:07:05 PM UTC-4 Edward K. Ream wrote: #4323 <https://github.com/leo-editor/leo-editor/issues/4323> discusses two recently discovered bugs. Both bugs involve @language directives, but fixing them involves entirely different design questions. This post discusses only bug 2.
*[snip]* *The tough choice* We have seen that good Leonine style dictates that all @<file> nodes should contain exactly one @language directive. The question is, what (if anything) should Leo do if that's not true? Changing the *rules *for how Leo writes @<file> nodes would constitute a breaking change to Leo. Potentially, existing Leo *outlines* might write existing external files differently! Leo's code could change, provided that the effect of the code remains exactly the same. Otoh, forgetting to add an @language directive to an @<file> node puts a time bomb into the outline. Moving node A might change the @language directive in effect for node A. As a result, Leo may mysteriously fail to write the external file correctly! In short, bug 2 may be rare, but it's far from harmless. *A possible solution* PR #4324 provides a fallback policy. The PR uses the language implied by the external file's extension to set the language (comment delimiters) to be used when writing the external file. This policy makes @<file> nodes self-contained. Alas, this policy *might* cause existing Leo *outlines* to write existing external files differently. This could happen if the @language directive in effect for node A did not match the language computed by the file's extension. This actually happened in several of Leo's unit tests, but the PR easily corrected that problem. If a new policy is going to be applied, I think a new leo version sentinel should be applied. The current one reads: #@+leo-ver=5-thin The read code might have to branch on the version, but that should be OK. One potential problem would be @files written by the new code but read by an older version of Leo. This could only be a problem if a new @file is sent to someone who is running an older version of Leo. Otherwise, I agree that without an @language directive the file extension should take precedence. We would have to decide how to handle the case where this extension is not known to Leo. I also agree that having more than one @language directive makes for an impossible situation and would have to be handled. Warning messages should be more informative than are the current ones about not writing a file because of orphaned nodes. I'm never sure if it means that the outline hasn't been saved or that the external file hasn't been saved, and I don't know either what to to to fix things nor whether my work will be lost if I save (or don't save) the outline. I am inclined to think that if an outline is saved that contains an invalid @file, that file's headline should be changed to "@@file" so that all the nodes will be saved as is. This will prevent corrupting an existing external file. Of course a warning message would have to be given to that effect. -- 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 visit https://groups.google.com/d/msgid/leo-editor/ebca596a-4441-4346-b730-ec9584a3edecn%40googlegroups.com.
