Show additional following lines of a tagged line in Focus tag... mode

I use the .todo mode with additional information in the lines following a task, for example

  • task 1 @today
    some useful information or links to task 1
  • task 2

If I now focus to @today tag, I wanted to see the useful information for task 1 as well and not only the task itself. Is that possible or do you have an idea? In TaskPaper I can do that by tagging the useful information instead of the task itself but that do not work in FT:

  • task 1
    some useful information or links to task 1 @today
  • task 2



Try this example document:

[Find done and descendants](x-foldingtext://documents/current?nodepath=%2F%2F%2F%40done%20union%20%2F%2F%40done%2F%2F*)

- one
	- a
- two @done
	- b
- three
	- c

If you click the “Find done…” link then “two” and “b” should be focused and event thing else folded away.

The way that it works is:

  1. I typed in this node path in to my document: ///@done union //@done//*. It says first find everything tagged with done and ancestors of those nodes… union with all descendants of nodes tagged done.

  2. I then selected that node path and did Edit > Run Command > Link Node Path. That turns the selected node path into a clickable link. Click and the node path is applied to your document, eventuating that doesn’t match is folded away.

Thank you, Jesse. That works fine even for other tags. Maybe sometimes you implement a “smart” solution by clicking the tag. :wink:

Jesse, is there any possibility of using a new line like “br” instead of a paragraph. Something like crtl+return in TaskPaper. That would be the solution.

In the next release of you Command-Click a tag then the children of tagged items will be included in the search results.

In the next version Control-Return will insert a line break character instead of paragraph break. This means there will be a visual break, but the text will all be considered part of the same node.

But at the moment there’s a cursor display problem when the cursor is on that break. I’m going to see if I can resolve, but not sure.

Both will be very good!

Just noticed: I put the following at the top of my document:

[Today](x-foldingtext://documents/current?nodepath=%2F%2F%2F%40today%20union%20%2F%2F%40today%2F%2F*) | [Next](x-foldingtext://documents/current?nodepath=%2F%2F%2F%40next%20union%20%2F%2F%40next%2F%2F*) | [Due](x-foldingtext://documents/current?nodepath=%2F%2F%2F%40due%20union%20%2F%2F%40due%2F%2F*) | [Important](x-foldingtext://documents/current?nodepath=%2F%2F%2F%40important%20union%20%2F%2F%40important%2F%2F*)


Now my text doesn’t fold! Removed, and folding works fine. Anything obvious to bear in mind, or is there a bug at play?

To clarify: selecting all text and attempting to fold doesn’t work. Folding individual items works as expected with the node path links in there.

That, and with the above node links command-/ works to unfold all text, but not to fold it up again…

EDIT: solved. the command-a, command-/ to fold the whole document shortcuts don’t seem to work if the document doesn’t begin with a header line? (#)

Can you attach a small sample document that shows the behavior. I’m not sure that I follow what’s going on.

So the behaviour isn’t specifically to do with the node links I posted. I’ve demonstrated with a few empty lines but it’s the same when I put a couple of links on my first line— selecting everything and pressing the command-/ shortcut to toggle folding on all nodes doesn’t work (for me). This might be expected behaviour with regard to the structure of a document? It threw me.

Ok, I see what you mean. This is expected behavior in one case, not in the other, let me explain what’s going on:

  1. All items have a “structure level” that’s used to determine the underlying tree structure, folding, etc.

  2. List items always start out indented 1 level relative to body text. So if you have a line of body text, followed by a list, then the list is considered indented under it.

  3. When you do “Select All” and then some command, often that command will process only the common parent nodes in that selection.

That’s what’s happening in the first case you mention (with line of links at top) the top line is considered the common parent of the selection. And so only it is folded. I’m a bit confused by your “no fold” comment in the original report of this problem… I would have expected the line with all of those links to fold all of your lists under it.

In the second case, where you add empty line, something similar is happening… but empty lines can’t be collapsed. In that case I think the list items should still collapse, working on a fix for that now.

Thanks Jesse! Figured document structure might have something to do with it, but as you say, the condition with empty lines threw me. Not a biggie, though.