Bike 1.17.2 (165)

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 :).

1 Like

Few things…

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 :slight_smile:

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.

ChatGPT knows surprisingly much about TaskPaper, it’s even able to code stylesheets and more complex javascripts.

I suppose ‘complex’ depends on the level of expertise, but I’ll give you a real world example. I’m preparing for my week of writing revisions and I have a bunch of notes that I need to work through. I’ve already prioritised these by dates, but there’s hundreds of them. Let’s say that I want to filter out items that are note types, have a @due tag and are due in one week (including overdue), and I want to include the children of those items in the search results (because I don’t want to manually expand the search results each time). Of course, @done items should not be included. It took me roughly 30 minutes to establish this query:
@type = note and @due <[d] +1w and not @done///*

I tried to do the same query in Bike, and ended up with this after 20 minutes, with the documentation open.
//note "@due" and not "@done"///*

I’m not sure how far support for date parsing goes in the current version, so I ignored that.
Where it gets confusing for me is the ///* operators, and even <[d] +1w is not immediately obvious. Steps, axes, slicing…it makes sense once you see an example, but that’s 1 hour spent on a simple natural language query that would read: notes due in one week including descendants except done.
Or maybe: is:note due:next week and not status:done descendants:yes

I don’t know how much autocomplete would help, but if it helps with structuring the query so that the more obscure operators are correctly placed, that’s a win.

Here’s an example of a brilliant interface for outline filtering, combining icons for the most common use cases and advanced text parsing for further options:

1 Like

I don’t know that I’ll got in that direction, but I would love to play with that UI some. Can you tell me what app it is?

Sure: The help section is a live app document.

Still working away on this release, but slow going

To help people understand what’s possible, it might help if the Using Outline Paths topic would mention that the syntax is based on XPath, and link to the spec, MDN web docs, or a cheatsheet.

If Bike only supports a subset of XPath, or adds other things, would be good to note that too. Pointing to the standard and documenting your deltas might allow you to simplify the docs topic.

1 Like

Gosh darn it, there WILL be a new beta release tomorrow. It’s taking a long time, not a bunch of new flashy features to show, but time to start releasing things again. Just one bug to fix in the morning.


Finally got a new preview release out!

Excepting any bugs (let me know!) that show up I think this is close to what I want for Bike 1.17 final release. Hope to make final 1.17 release early next week.

Outline paths still aren’t “done”, for example I want to add date support at some point, but I think the foundation is solid and extra features like dates can be fairly easily added later.

Lots of details have changed compared to the previous preview release, but big picture is still the same.

For outline paths I changed to color syntax highlighting. Warm colors are operators and controls. Cool colors are values. Generally they alternate in the syntax, so I think it makes them easier to visually parse. I decided against syntax changes (such as adding marker syntax for row types) and instead think the colors work pretty well.

I’ve also done a bunch of autocomplete work. I think it works really well for tags. Less certain about axes and axes type filters. In most paths I almost never need to specify these things (or I use a standard shortcut) so maybe the autocomplete is distracting. At the same time the autocomplete shows you all possibilities. I’m including it more as documentation then as something that will help you type faster.

The new run:: axes is an important addition. For one it’s needed for stylesheets, so that text runs can be styled. It also might be generally useful, for example could use to discover backlinks. When you see this search //*/run::@strong it is saying:

  1. For all descendants of the root node
  2. Look at their associated rich text by using run:: axes
  3. Run predicate agains the attributes associated with each rich text run’s attributes.

The last big addition to this release is that now you can use outline paths from Bike’s scripting dictionary and shortcut actions. Using outline paths can be much more performant (and less code) then performing filtering operations using the automation apis.

tell application "Bike"
	tell front document
		query outline path "//pizza"
	end tell
end tell

One complexity of outline paths is they can result in different kinds of values. For example a path such as count(//*) returns a number. While a path such as //* returns a list of “nodes”. In the case of Bike each node returned might be a row, or might be a text run.

Modeling all of that for consumption by AppleScript or AppleShortcuts would take a lot of work and add a lot of complexity, so instead of taken the cleanest path of least resistance.

  1. When using Bike’s shortcut “Query Rows” action only rows will be returned. count(//*) will just return an empty list.

  2. When using Bike’s AppleScript dictionary “query” command rows and numbers are returned, but text runs will not be returned. If you want to make a query that includes text runs what you can do is as a last step ask for the parents, and then you will get the rows containing the runs. For example:

    • //*/run::@strong - zero results in AppleScript since no text run results
    • //*/run::@strong/.. - returns all rows that contain strong (bold) text.

And there’s an updated icon! Thanks @Erlend for the ideas.


Exiting stuff!
Is this pushed to Setapp as well, if I’m on the beta program there?

Is this pushed to Setapp as well, if I’m on the beta program there?

No, I’m not using their beta system. Just posted here for now.

Just tried this for the first time with language set to JavaScript at the top left of Script Editor.

Using Scripts - Bike

It works very well !

Thank you !!

Expand disclosure triangle to view JS source
(() => {
    "use strict";

    const doc = Application("Bike");

    return doc.exists()
        ? doc.query({outlinePath: "//*/run::@strong/.."})
        .map(row =>
        : "No document open in Bike";
1 Like

Good, thanks for testing. This is one area where Bike’s outline paths can really do things that were not possible in TaskPaper. So yeah, progress!

1 Like

I’m updating docs this afternoon and have found a few small bugs in the process:

  1. Outline path step slice behavior isn’t quite right in current release. It should be a 1 based indexing system to match xpath, not a 0 based index system.
  2. Slice syntax highlight is also not right, should be gold/yellow.
  3. Autocomplete of attributes in choice view settings isn’t updating to include document attributes, just using the default ones.

Will make release this weekend that fixes these and any other issues that arise.


Thanks for all the testing and feedback. Bike 1.17 is out, will start work on next version tomorrow. Here’s a summary post and movie describing outline paths.

1 Like

I have a tiny piece of feedback (didn’t feel worth an entire thread) which is that I keep accidentally inserting new lines into my link titles because the text comes from copy and pasting from a browser, and it would be really cool if the newlines were trimmed out. Right now, if you want to supply a custom link title using the popup

it is very easy to paste in a multiline string, eg. if I double-click to select the title on the Arxiv page, then copy and paste, I get this:

which inserts an extra line into the outline because I copied the title, followed by a newline. This seems to happen to me very often – maybe an artifact of my browser text-selection technique… It’s even happened inside the middle of a link (when the link text had newlines in the middle). I think what I’d want is to make all link titles be one line, and trim any whitespace from the ends of the link text to prevent links from spanning multiple lines when setting the title.

1 Like

I’ll get this fixed in next release.


A post was split to a new topic: Bike to HTML

I think this is fixed in latest preview release:

1 Like