Changed outline path highlighting to better show path structure
Changed outline path syntax in many small ways, but generally same!
This release adds a run:: axis to outline paths. Use it to search text runs. For example to find all rows that contain bold text use the outline path: //*/run::@stong. To find all links to a com website use //*/run::@link endswith .com.
Also note that the Outline Path Explorer now shows text run matches. It also shows the text run attributes after the text they are associated with in your outline.
The focus of this release is to implement and document outline paths. I’m also working on an Outline Path Explorer tool to make them easier to understand. Outline paths are not terribly useful on their own, but will be useful later when I implement stylesheets and outline filtering. They are a big somewhat complex feature, so splitting into own release for early testing and feedback.
Thanks,
Jesse
To get preview releases through Bike’s software update select: Bike > Preferences > General > Include “preview” releases. Or download directly from Bike’s releases page:
Will the outline path explorer be solely for testing, or are you planning changes to its functionality?
I think that having the option to make the outline path explorer only show rows that match the query might be a nice option in the short term. I’m dealing with larger outlines, and the queries I am writing only return a handful of rows. Also, the ability to focus the cursor on a row that matches a query would be a plus.
Regardless of the outline path explorer’s future, I am excited to see how everyone else uses this new query language!
I think this is because the foreground document was probably never saved yet? To copy a path row link the outline document must be saved to a file path, so that the link can be generated.
It’s really intended just for testing and learning.
Again the goal is a testing / learning tool. I’m not sure if filtering that list would help in that regard. I feel like leaving all rows in place makes behavior clearer. I could add some sort of command to jump to next matching row if that would help?
Are you talking about from the Outline Path Explorer window? Or just as a general feature? I do plan to add outline path support to Bike’s scripting API, and I think it will be pretty easy to make a script to do this once I’ve added that support.
To avoid any confusion … in the current preview release I actually have two Outline Path implementations. I have the older (which is used in the Go / Focus Heading) panel. And I have the newer which is used in Window > Outline Path Explorer.
Generally they are same design, but lots of details different. If you are unsure why the path that you’ve tested in the Outline Path Explorer isn’t working as expected in the above panel… that’s why.
I’ll fix this soon and move over to the new implementation everywhere.
I’m thinking of making row type testing in outline paths a little more explicit by adding syntax. For example to search for all tasks will change:
From: //task
To: //::task
This will do three things:
Make it possible to autocomplete row types. Type :: then then I will know to show types popup
It composes well with axis names. For example //ancestor::task to find all task ancestors.
Make syntax rules a bit simpler. If you want to find the text “task” in your outline you can just type it normally, //task and don’t have to use quotes like you do now //"task"
Thoughts? Got a better idea, or improvement to this idea?
Is there any preference for keywords vrs symbols? For example right now we have keywords for combining paths:
union
intersect
except
And predicates:
and
or
not
I’ve had suggestion to replace those with symbols: && = and, || = or, and ! = not. The end result is more cryptic…, but also takes away a number of confusing edge cases. Such as when you try to search for “and”. And generally makes it easier to pick out the path operations from the path values.
When I first thought on this I didn’t want to do it, but then I remembered that when I want to combine paths I can never remember any of the keywords except for union. If instead we replaced + = union, * = intersect, and - = except, I think I could remember that much easier. I think it’s maybe just easier to explain to. Add one path results to there other. Subtract this path … ok multiply to intersect isn’t as easy, but I think the change is overall an improvement.
So I think I will change to math symbols for the set logic. I’m less sure about and, or, and not… but at the moment probably will just to keep the style the same.
Or maybe I won’t if you have a reason why I shouldn’t Let me know.
Thanks for ideas, I’m still in considering process.
For me I’m not too bothered by * for intersect. It’s already the most confusing set operation (for me at least) and I think used the least frequently. I think OK to make it a little more confusing if union and except become a little easier.
But again I’m not sure about any of this.
I was going off the xpath 1.0 spec, where they do not have union, intersect, or except, and instead only used “|” for union I think. Anyway I just noticed that in later versions of xpath they do use the terms union, intersect, and except. So maybe I should just follow that precedent… that would be easiest.
Anyway, more feedback welcome. I probably won’t make any changes to keywords today.
I do think I will start adding some marker to row types today though. Current thought (these things change every second) is to mark the type with a colon after the name. So like:
//task: pizza
/descendant::task: pizza
And current thought after that is that I’m overthinking, and should work on autocomplete first! Just realized I don’t really need any extra syntax for autocomplete. And maybe I should just make row types stick out with stronger syntax highlighting. Ha!
As a non-coder, let me just point out that even TaskPaper search currently requires me to use chatGPT to come up with search clauses for some of the more advanced filtering I do. It’s powerful, but limiting to users who need to learn a new type of language to interact with the app. It requires time that can otherwise be spent on getting things done. That said, it is 2023, we do have AI tools that make this easier, but my vote goes for natural language syntax wherever possible, especially if we’re considering future iOS UIs where inserting obscure characters into a tiny window is painful.
That said, I realise I may be the minority voice here, so I’ll be ready for anything
I like the @ prefix for attributes, and I see no reason why you could not use it for row types, too. After all, a row type is a kind of attribute. So @task, @heading, etc. Nice and simple
Since the path language includes attributes, I assume that the UI will allow specifying attributes for a row. One way would be just typing the attribute into row content with @ prefix. The other way is a separate entry field. If a field is used, perhaps the field should treat text with no @ prefix as the “name” of the row. This name would be searched instead of the row contents in an outline path. And what is the use case you might ask? Don’t know, it just sounds intriguing!
I’m sure (well at least I expect) there must be many more non-coders using Bike than coders. Would love to hear more of your thoughts. For example I’m definitely surprised to hear that your are needed to do complex queries… and able to use ChatGPT to help. TaskPaper query language is pretty niche, and there’s not really any spec, I’m amazed it can help.
I would very much like to improve upon TaskPaper query language in ease of use. I don’t think syntax changes will help all that much, I think more useful will be tools and documentation. With that in mind please do read through Bike’s outline path documentation and let me know what you think.
It’s a work in progress, but (compared to TaskPaper’s similar documentation) I’m trying to have less descriptive text and more example queries. Please let me know what parts work for you and where you get lost. For me (I forget TaskPaper syntax too) examples are usually most helpful.
Also let me know what additions you’d like to see to the Outline Path Explorer. I’m in process of adding autocomplete. TaskPaper did autocomplete for tag names, but I’m hoping to allow autocomplete for many more things. So you’ll be able to see various structure options as you type.
I’ve also added the parse tree representation to the Outline Path Explorer … does that help at all or maybe it doesn’t help at all :).
First all the type syntax talk is about a shortcut for type check. You can already do @type = heading. I’m less sure about instead using /@heading as the type test. Generally the attribute mechanism is @NAME fetches associated value. I guess you could think of @heading fetching a boolean value… but it doesn’t seem quite right to me. And it would also mean that we have an ever growing list of special names that can be used as normal user attributes.
For now I still like trailing colon best. Though that might change, so I’m not working on parser for a few days
Yes, this won’t be in current release, but is definitely in the plans. I’m pretty sure I will use a separate entry field, but I’m not really sure how the UI for it will work.
I think I see what you mean, so you would be changing the default search behavior. It does sounds interesting, but I don’t think I would want to do this unless there was a really good use case. First I need to implement actually filtering and see what we have. And that’s a good few months of work I’m afraid.
Let me know.
