Request: Search feature should optionally show child nodes

TaskPaper
1

TaskPaper respects and endorses hierarchical data.
I.e. we can create hierarchical data, fold children away, when we move a node it moves children, etc.

However, when we search for a node, we don’t see children (which are a very important par of a node’s data).
Could we have a search modifier or some feature that would display child nodes during a search?

Thanks.

2

I am not sure exactly what you are thinking about, but Taskpaper already does what you asked for and a lot more.

Here is a link that explains how to do what you mentioned. Read it and if you need help with a particular query create another post and I or several others who are a lot more knowledgable can help you.

2 Likes
3

You can include children (or all descendants) of all or specific types:

Tagged lines and paths to them:

@sometag

The tagged lines and all descendant lines, of any type:

@sometag//*

The tagged lines and all descendants, except note paragraphs:

@sometag//(not @type=note)

The tagged lines and immediate children (but not deeper descendants)

@sometag/*

etc. etc.

1 Like
4

Thank you. That’s what I needed.
I wasn’t aware of the guide. Help took me to this forum.

5

Greetings,

@next//* does’t work in TaskPaper preview 3?

It shows only the FIRST line tagged @next and its children.

However, it does not show ALL lines tagged with @next and its children.

What am I doing wrong?

6 
@next//*

Seems to be working here – returns all lines tagged at the end with @next, as well as their descendants … (elements actually indented beneath them, not following peers)

(Ver 3.0 Build 166)

7

Oh, I got it. It shows the ONLY @next that has descendants, but not those that do not.

So, back to the question:

How to show all lines tagged with @next, expanding descendants if they exist?

@next or @next//* shows the same as @next//*, and trying to add parenthesis makes the whole expression invalid.

8

First thing that comes to mind is:

@next union @next//*
1 Like
9

That works. Thanks!

10

For a stored search, you could also write:

@next/descendant-or-self::*

(In a script, I might use this version – it’s a single search. The union version is perhaps simpler to type, but technically involves combining two separate searches. With huge files I guess you might just be able to measure a speed difference, but the engine is so fast anyway, that ease of typing is probably a good bet … )

1 Like
11

I think I’m going to add a shortcut for the descendant-or-self axis in the next release. It seems to come up a lot in TaskPaper searches. Any ideas on what would be most suitable. So far for shortcuts we have:

  • .. for the parent axis. For example @next/..* matches the parents of all @next tagged items.
  • / for the descendant axis. For example @next//* matches the descendants of all @next tagged items.

Given that, what should the shortcut for the descendant-or-self axis be?

Here are some alternatives:

@next/descendant-or-self::*
@next/./*
@next//.*
@next///*

Or maybe there’s a convention from shell glob patterns glob (programming) - Wikipedia that fits well?

1 Like
12

That sounds good.

Personally I find that the dot in

@next/./*

reads well as a reference to self.

(Would the 3 slash version have the same meaning as in FoldingText searches ?)

13

No, so far I’ve been avoiding that. Instead in TaskPaper I just always include the ancestors when displaying search results… instead of needing a special syntax for that. I guess probably best to avoid that syntax since it already has a meaning in FoldingText.

14

Sounds sensible. And I notice that I’m beginning to feel that perhaps @next//.* would be quicker to type : - )

1 Like
15

I agree… it just looks less messy too. The syntax order (/ then .) also maps better to the order of descendant-or-self::. The only issue is that I have with it is that the . character visually mixes in with other content characters to me and still looks a bit messy.

I expect these kinds of searches to become more important going forward, and I want a really clean syntax…

In the next release I’m going to be switching the focus/hoist to go back to what I hard originally, and only show the children of the hoisted item. I know it’s not what people are used to from TaskPaper 2, but I think it’s cleaner conceptually and avoids a bunch of interface problems and special cases.

But when I make that change I also want to provide some clean way to do descendant-or-self:: searches so people can get the TaskPaper 2 behavior if they want. With that in mind what do people think about changing the // shortcut to map to descendant-or-self:: instead of mapping to descendant::. It diverges from the Xpath spec, but I think is the preferable default for TaskPaper?

16

A shortcut for descendant-or-self:: would be really handy. I’m using it in almost all of my filters.

For now, I don’t have an opinion about changing the // shortcut, but from the first options provided, I prefer @next//.*.