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.
