I suppose that the main trick is to understand what is in a postamble and how to know that it isn't part of the last method of a class. Aside from that, the indentation of an "@others" line (and a "<< section >>" line) would equal the indentation of the first line of their text. This would leave uncertain the right location for a comment that wasn't indented enough by mistake of the author. One would not want to end a block too soon because of a minor typo like that.
On Tuesday, August 12, 2025 at 8:06:44 AM UTC-4 Edward K. Ream wrote: > This ENB discusses possible fixes to #4419 > <https://github.com/leo-editor/leo-editor/issues/4419>. It is mostly > notes to myself and discusses experimental ideas. Feel free to ignore it! > > *Executive Summary* > > *x.gen_blocks* generates a tree of *nested* blocks. Instead, it might > create a list of *sequential *blocks. > > This new scheme greatly simplifies complex code, but several new and old > problems must be resolved. > > *Background* > > This thread > <https://groups.google.com/g/leo-editor/c/EdML7vrZAaY/m/KFbmb9XkBgAJ> > started the train of thought. *i.preprocess_block*s moves lines between > blocks just by incrementing two ints! As a result, my attention rested on > the* i.Block* class. > > I had forgotten that *x.gen_blocks* generates a tree of *nested* blocks. > This seemed unnecessarily clumsy. After all, the key invariant is that > blocks must cover the source code *without gaps*. > > What was going on? Well, I was focused on accuracy above simplicity. But > the resultant complexity obscured possible simplifications. > > *The Aha!* > > Generating nested blocks is tricky, as you can see from the base > *i.gen_block* method. Furthermore, i.gen_block relies on *i.find_blocks*, > another complex method! Worse, the overridden *python_i.find_blocks* is > truly hairy. > > Why did I choose this approach? Because it allows all importers to know > the *end* of each block. You would think this would be essential > information! > > But Aha! *Suppose each block ends with the start of the next block? *At > first glance, this would be a perfect solution! > > Finding blocks becomes much more straightforward. See the experimental(!) > version of python_i.gen_block in PR #4422 > <https://github.com/leo-editor/leo-editor/pull/4422>. This version > replaces the (complex!) legacy helpers (*python_i.find_blocks* and > *python_i.find_end_of_block*) with the much simpler > * python_i.find_start_of_body*. > > But the new scheme won't work immediately. *Blocks representing classes > will end with their first method!* Such blocks will be equivalent (in > some ill-defined sense) to: > > class MyClass...: > <preamble> # Everything before the first method. > @others > > This won't do. We must generate something like this: > > class MyClass...: > <preamble> > @others > <postamble> # Anything following the last method. > > Finally, let's discuss underindented lines. This is an existing problem > that can't be solved in a truly satisfactory way because Leo no longer has > a way of representing underindented lines. Leo's legacy importers handle > such lines by generating code like this: > > class MyClass...: > <preamble> > @others > <postamble> > > The relevant code is buried deep in the weeds. > > Imo, the new importers must handle underindented lines in the same way. > > *Summary* > > Using a list of sequential (non-nested) blocks promises to simplify *all* > importers, > not just the Python importer. > > However, the PR is highly experimental. Complications may appear. We'll > see how this scheme pans out. > > 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 leo-editor+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/leo-editor/e72410e1-0b9f-46fc-acd6-e6ef1d912dc2n%40googlegroups.com.
