select_h() a method of class poslist looks NOT at the nodes in the poslist, but at the IMMEDIATE CHILDREN of these nodes

[SegundoBob]

Ville M. Vainio's suggests that c.find_b() and c.find_h() be used.
See post:

http://groups.google.com/group/leo-editor/tree/browse_frm/thread/9894b776c2afffb2/f463563852449389?rnum=1&_done=%2Fgroup%2Fleo-editor%2Fbrowse_frm%2Fthread%2F9894b776c2afffb2%3F#doc_57e3cd4de8201b9b

Looking at either c.find_b() or c.find_h() you can see the
recommendation:

You can chain find_h / find_b with select_h / select_b like this
to refine an outline search::

pl =
c.find_h('@thin.*py').select_h('class.*').select_b('import (.*)')

So I tried a few simple tests using select_b() and select_h(). I
found that select_b() works just as I would expect, but select_h()
surprised me. Puzzled I looked at the definition of select_h() and
found "Find immediate child nodes of nodes in poslist with regex."

Wouldn't it be better for select_h() to be consistent with
select_b()? Wouldn't it be better for them both to search the nodes
in poslist?

Using the Nav tab on LeoPyRef.leo and leoPluginsRef.leo for 4.8-final,
I could not find a single use of select_h(). Hopefully, there is time
to change select_h() before there are too many dependencies on its
current behavior.

[Ville M. Vainio]

On Sun, Dec 12, 2010 at 12:03 AM, SegundoBob <bhos...@ieee.org> wrote:

>    You can chain find_h / find_b with select_h / select_b like this
>    to refine an outline search::
>
>        pl =
> c.find_h('@thin.*py').select_h('class.*').select_b('import (.*)')
>
> So I tried a few simple tests using select_b() and select_h().  I
> found that select_b() works just as I would expect, but select_h()
> surprised me.  Puzzled I looked at the definition of select_h() and
> found "Find immediate child nodes of nodes in poslist with regex."
>
> Wouldn't it be better for select_h() to be consistent with
> select_b()?  Wouldn't it be better for them both to search the nodes
> in poslist?

How would you chain select_h's if they merely pruned down the current poslist?

--
Ville M. Vainio @@ Forum Nokia

[SegundoBob]

> How would you chain select_h's if they merely pruned down the current poslist?

I missed the intention of your definition of select_h(). I agree that
descending the tree is usually (and perhaps always) more useful than
pruning the current level.

I suggest making the functions simpler and the facility more flexible
by adding a method children() to the poslist class. This method would
correspond to method p.children(), which returns only the "immediate
children" of position p. And, of course, change select_h() to prune
the positions in the poslist, instead of the children of these
positions. This would make descending the tree explicit, less
surprising, and more flexible.

If you think conciseness is more important than simplicity, you could
add two new methods to the poslist class: children_h('pattern')
(equivalent to the current select_h()) and children_b('pattern').
And, of course, change select_h() to prune the positions in the
poslist, instead of the children of these positions.

[Ville M. Vainio]

On Tue, Dec 14, 2010 at 6:46 PM, SegundoBob <bhos...@ieee.org> wrote:

> I suggest making the functions simpler and the facility more flexible
> by adding a method children() to the poslist class.  This method would
> correspond to method p.children(), which returns only the "immediate
> children" of position p.  And, of course, change select_h() to prune
> the positions in the poslist, instead of the children of these
> positions.  This would make descending the tree explicit, less
> surprising, and more flexible.

You can see that I agreed in march 2009:

http://www.mail-archive.com/leo-e...@googlegroups.com/msg05704.html

And, I still do.

I don't know why I never got it done. Probably ended up being too busy.

If you feel like implementing the feature in trunk now, go ahead with
my permission ;-).