Bike Outliner adds row types!
Use row types to add another level of structure and meaning to your outlines. You can now inlcude heading rows, task list rows, ordered list rows, and more.
Bike 1.13 with row types is out!
Hope you like it, and let me know what you want me to work on next:
Go to heading. Similar to TaskPaper’s “Go to project” UI. This work would be immediately useful.
Bike query language. Similar to TaskPaper’s query language. This would just be implementation of query language, and exposing scripting API to run queries… no search or filtering in Bike’s UI yet. This work would be less useful immediately, but is necessary foundation for future filtering and stylesheet features.
0 voters
Hope you like it, and let me know what you want me to work on next:
Interpreting this a little more widely than a multiple choice of two, by far my most burning request is user-customisable stylesheets. NotePlan enables me to set up a small range of custom text colours as alternate highlights, determined by custom fence glyph combos. A similar possibility in Bike (or any other way of setting word-specific text colour) would make it virtually feature-complete for me. Thanks, Nick
In that case I think you want the query language option. I expect the stylesheet matching rules to be specified (at least mostly) using the query language. So I need to get query language done first.
I think your use case (matching specific text patterns) can also be handled by that system, but I hadn’t really considered that use. I’ve added a note, but when you see me start to work on stylesheets, make some noise if what I’m building doesn’t supported your needed behavior.
Note … at the moment it seems like I’ll be working on go to heading next. That will take a week or two, then I expect to work on query language.
Nice feature! Suggestion: Turn off auto capitalization and text fixing for code block row types.
If in your demo you had typed
``` codeblock
it would have been auto-corrected to:
Code block
because of the auto-correct. It seems very rare to ever want auto-correct turned on for code block rows.
cheers.
I agree, this is needed. Will try to get in soon.
It would also be nice if it could preserve leading whitespace. Pasting a block of code in right now loses indenting.
I think this is already working for tab indented code, and actually now that I try it works for space indented (4) code too. Maybe the code you were pasting was 2 space indented? Try converting to 4 spaces and I think it will work.
Question:
I use a script that adds strikethrough and a @done(YYYY-MM-DD) “tag”. I think it’s posted on the Bike Extensions wiki, though I did use ChatGPT to translate that thing to AppleScript. Anyway, the original script doesn’t seem to apply any specific attribute to the row, just formats the text and appends the @done tag.
I have now replaced that script to toggle the “done” attribute and append the @done tag, which does as expected. But because there might be “native” tags coming in the future, I want to make sure the script doesn’t cause filtering problems down the road. Because ChatGPT built it after a few trials and errors, it might also be needlessly complex.
Any suggestions/words of caution? 
tell application "Bike"
tell front document
set selectedRow to selection row
-- Get the current content of the selected row
set currentContent to name of selectedRow
-- Check for the presence of a data-done attribute
set hasDoneAttribute to false
set doneAttributeValue to ""
repeat with attr in attributes of selectedRow
if name of attr is "data-done" then
set hasDoneAttribute to true
set doneAttributeValue to value of attr
exit repeat
end if
end repeat
if hasDoneAttribute then
-- If a data-done attribute is present, remove it
delete attribute "data-done" of selectedRow
-- Only attempt to remove the @done tag if the attribute's value is long enough to contain a date
if (length of doneAttributeValue) ≥ 10 then
set tagToRemove to " @done(" & text 1 thru 10 of doneAttributeValue & ")"
if currentContent contains tagToRemove then
set name of selectedRow to text 1 thru -((length of tagToRemove) + 1) of currentContent
end if
end if
else
-- Get the current date in the desired format
set currentDate to do shell script "date '+%Y-%m-%d'"
set currentTimestamp to do shell script "date -u '+%Y-%m-%dT%H:%M:%SZ'"
-- Add the "data-done" attribute with the current timestamp value
make new attribute with properties {name:"data-done", value:currentTimestamp} at selectedRow
-- Append the "@done(YYYY-MM-DD)" tag to the content
set doneTag to " @done(" & currentDate & ")"
set name of selectedRow to currentContent & doneTag
end if
end tell
end tell
What is the problem that you want to solve ?
( I can’t speak for others, but I personally don’t get involved in cleaning up after LLM effusions 
)
Currently when I toggle the done status through outline-spacebar, it visually only applies strikethrough and toggles the checkbox in the task box. I understand that it also applies a done attribute in the back end. I want that AND add a @done(YYYY-MM-DD) at the end of the row text, which currently Bike does not do out of the box.
I want to future-proof this workflow so I won’t have issues later with tag filtering if visible @done tags are added by Bike devs.
PS: I did notice the script I posted only works on the current date. Let’s ignore that issue for now, I just want to know what to look out for.
I think any filtering mechanism that Bike acquires would be able to filter on attribute names and values.
I’m not sure that adding visible tags would make much difference there.
Perhaps a question of crossing bridges when you get to them ?
If visible tags ever acquired special affordances, it would be easy enough to write inline tag ⇄ attribute code then.
I think the script looks good, the attribute and date format both match what Bike’s using internally, so that’s the important part. Eventually I expect Bike to add tags. And when it does that I expect it to render a tag with a date for data-done. At that point the @done() will become bit redundant, but won’t hurt anything.
Update Maybe to make things a bit clearer… when future Bike renders a tag, I don’t expect that tag to be part of the text content. It won’t be a syntax highlighted tag that’s part of the row content such as @done(value)… instead it will be rendered as a separate UI element, kinda how the numbers in numbered rows are now rendered separate from the text content.
So I guess that if there is any role for scripted addition of TaskPaper-style textual tags at this point, it’s really not a future-proofing role.
(possibly a temporary role in toggling a kind of visibility for attribute values ?)
Yes, I think that’s it. And also I’m not 100% sure how I’ll implement tags in the end, but I “think” it will be separate from body text.
I must look up the HTML/XML spec for the character set from which attribute names can be drawn.
( possibly smaller, I would guess, than the character set recognised by Taskpaper for tag names ?)
I’m not sure, but it seems to be relatively flexible. Chinese and Hebrew characters seem OK. As do dashes and underscores. Generally I think it should work.
The markdown script doesn’t translate to row types automatically. (v1.13)
If I select the text and use cmd+k to change the row type, the app would crash when I hit Esc.
Bike error message.txt (26.4 KB)
Which one do you have in mind ?
( I’m not aware of one that has been written since row types were introduced, so I guess you may have tried something that targeted earlier versions of Bike)
If you can describe the use case, and the problem that it aims to solve, we may be able to draft something.