Really interested in your ideas for creating views. I think clones do have
a place and they're great to have when you need them but I don't think
think they are the answer for views and I think using them as such is a
workaround to a cleaner view functionality.
I recently also thought about views and my conclusion was that what would
look cleanest would be a "hoist" operation, but rather than hoisting a
single node you'd hoist a collection of nodes which you've marked/tagged
somehow.
To take this to its logical conclusion there would be a pane similar to the
bookmarks pane except it would be a "quick-view" pane and each entry would
cause a hoist of all the nodes marked/tagged with the text represented on
each "view" button in that pane. In addition to manually tagging nodes you
could create views with a "tag-find-all" command and a button would be
added to the "quick-view" pane.
Would be interested to know what you think of that idea.
On Thursday, February 11, 2016 at 11:40:32 AM UTC-5, 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.
