>________________________________
> From: Edward K. Ream <edream...@gmail.com>
>To: leo-editor <leo-editor@googlegroups.com>
>Sent: Friday, February 19, 2016 8:16 AM
>Subject: New direction: attributes and views
>
>Point 3 of the overview thread was:
>
>> There is a close relationship between views and attributes. Indeed,
>> attributes create views, and vice versa. Examples: bookmarks, chapters, Nav
>> pane results,
clone-find-all results, whatever.
>
>This post is long and technical. It's worth doing because it unifies several
>related concepts.
>
>Assertion:
>
> A view is a set of positions satisfying a Leo predicate.
I suspect that the views I create and use are a set of positions selected
manually. The two cases where I most commonly use views (presented with the
bookmarks plugin in my case) are leo debugging / coding, where I'll collect a
set of nodes that form part of a call chain, but very often a gappy subset of
the callchain, skipping links that just pass through the vars I'm following,
and Django coding, where you want the python, javascript, css, and html that
interact collected together rather than in their separate sub-subdirs.
So there are views that can't be defined by a codable predicate.
Cheers -Terry
>A Leo predicate is a function/method/expression taking a position argument
>that returns True or False. A position p satisfies a predicate if the
>predicate returns True for position p. >
>The notion of predicate is useful for two reasons:
>
>1. It is a unifying concept and
>2. It may be possible to make predicates an explicit part of Leo's ui.
>
>Predicates naturally define attributes, and vice versa. We want to be able to
>form the union or intersection of attributes. Richard has brought my attention
>to Jake's nodetags plugin. This plugin adds, deletes and searches for
>attributes.
>
>Find by predicate
>
>The essence of the idea is the following super-simple code:
>
>
> forp inc.all_unique_positions():
> ifpredicate(p):
> <<dosomething >>
>I'll say more about this in another posting (there is now a
>c.cloneFindPredicate method that does a lot of cool things).
>
>In fact, the predicate could, as a side effect, do "the something", in which
>case the code is:
>
>
> forp inc.all_unique_positions():
> predicate(p)
>Important: the code is inherently dynamic. The predicate can be re-evaluated
>as the outline changes.
>
>Important: this code is maximally general. The quicksearch (Nav) nodetags and
>bookmarks plugins are examples of this pattern. For the Nav plugin, the
>predicate is that p.h matches the search string. For the nodetags plugin the
>predicate is that p.v.u matches a particular tag. Similarly for bookmarks. Do
>you see?
>
>Important: This code is very fast.
>
>As I was thinking about this topic I realized that the chapters code is
>really, really stupid. On startup it looks for an @chapters node and requires
>that all @chapter nodes be children of this node.
>
>Instead, the code should allow the user to create an @chapter anytime,
>anywhere. Yes, the code that shows available chapters must rescan the
>outline, but tests show that can be done in less than 0.1 sec. As a happy side
>effect, there is no need for a ChapterController class to retain state.
>Stateless chapter-related commands should work.
>
>Summary and new directions
>
>Predicates create a set of positions, namely the positions that satisfy the
>predicate. These sets naturally form distinct views of an outline. If we clone
>the nodes in the set under a common node, we can hoist that node and see all
>and only those nodes that satisfy the predicate.
>
>The bookmarks, todo, quicksearch and nodetags plugins provide alternate,
>arguably better, ways of seeing such views. Most people will find these
>plugins more easy and intuitive to use than hoisting a set of clones. I'll say
>more about this in another thread.
>
>Predicates could be incorporated into any plugin. The ui would allow the user
>to predicate expression. The plugin would then filter all nodes based on the
>predicate.
>
>Edward
>
>P.S. We can imagine predicates being represented directly in the outline by
>@predicate nodes. For example, the body of such a node could be:
>
>
> defis_chapter(p):
> returnp.h.startswith('@chapter ')
>
>or even just:
>
>
> p.h.startswith('@chapter ')
>Leo's support code for @predicate would take care of the details of applying
>the expression or function to every node of the outline.
>
>EKR
>
--
>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 post to this group, send email to leo-editor@googlegroups.com.
>Visit this group at https://groups.google.com/group/leo-editor.
>For more options, visit https://groups.google.com/d/optout.
>
>
>
--
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 post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
