Hi Edward, Concerning blank lines, I have a Leo script which corrects blank lines between main blocks and between methods:
https://github.com/benzolius/leo-scripts/blob/master/correct_empty_lines.py Sorry, is full of hard coded stuff, but the second part of the script corrects over 90% of blank line problems. Regards Zoltan On Thursday, February 11, 2016 at 6:40:32 PM UTC+2, Edward K. Ream wrote: > > I'm decompressing from the intense programming I've done recently. The > decompression phase is often the time when new ideas arrive. Here are some > recent ones: > > 1. I love clones, I hate clones. > > I used clones intensely in the make-stub-files project. > > - For unit testing, I moved clones of all code needed by the @test node to > be children of the @test node. *Considered in isolation*, this looks > like the ultimate unit-testing pattern. There is never any need to execute > the unit test externally because all code is up-to-date. > > - I've just created a set of "views" on the code that would help > *experienced* Leo users understand the code. > > Alas, this *expert* usage of clones comes with a price. Views will > bewilder people who don't use Leo. Second, clones gum up searches, even > (especially) for experts. Every unit test created its own set of clones! > > The clone-find-all commands are kinda a workaround, because I can search > just from the created node to the end of the file. But these commands > create *more* clones, so if I search from anywhere else the situation > just gets worse. Boo hoo. > > This morning a new thought arose. Is it possible to use an improved Nav > pane to avoid the problems with clones. In particular: > > A. I want a way to mark (with an attribute) nodes to be incorporated into > unit tests, as if they were cloned as children of @test nodes. It should > be possible! > > B. I want a way to mark (with an attribute) nodes that are part of a > view. Richard et. al. may already have done this! My requirements are > probably more stringent than most people's. I'm excited to think of the > possibilities. > > 2. Minor problems with @clean. > > @clean was a *huge *success for this project. GvR might not have looked > at make_stub_files.py if it had been produced by an @file node. > > A minor annoyance: it was easy to forget to put a single blank line in > front of def's, and two blank lines in front of classes. The diffs looked > bad when I forgot, so I wrote the following Leo script to check for blank > lines. > > @button check-leading-lines > for p1 in c.all_unique_positions(): > if p1.h.startswith('@clean'): > for p in p1.subtree(): > if (not p.h.strip().startswith('<<') and > p.b.strip() and not p.b.startswith('\n') > ): > print(repr(p.b[:3]), p.h) > print('done') > > Hehe. This morning I realized that it might be possible for the @clean > read/write code to insert the blank lines automatically. It's worth doing. > > 3. Markdown problems. > > @language rest is needed to render the docs properly within Leo, but Leo > converts @language rest to @language md when reading files whose extension > is .md. Annoying. This should be fixed somehow. > > 4. Diffs. > > I committed many times every day, and each time I was annoyed at what git > diff showed for .leo files. A few months ago I experimented with having > *Leo* be the diff agent, but a) that didn't work well even for me and b) > it's out of the question for people who don't use Leo. > > It would be good to create a git plugin/addon that would more clearly show > diffs to .leo files. The requirements are actually very simple: > > - Ignore all html elements except <t> elements. > - Strip <t> and <\t>and show only diffs to the body pane. > - Show the headline in the diff. > > The result could be awesome! > > 5. Improving Leo's make-stub-files command. > > It's really bad to have two separate code bases. Instead of folding the > make-stub-files code into Leo by hand, make_stub_files.py should become > part of the leo/external folder. > > Also, Leo should have an update-stub-files command which would be like > using the --update option. > > That's all for now. I'm excited to start working on all these projects, as > well as the task-oriented docs that promise so much to newbies. > > 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 post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
