Bike 1.13 (145)

  • More space to click before text when row mark is shown
  • Disable text formatting pallet buttons in OPML outlines
  • When paste plain text apply current row type to inserted rows
  • Working on final release notes…

Bike now supports row types!

Use row types to add another level of structure and meaning to your outlines. You can now include heading rows, task list rows, ordered list rows, and more.

The easiest way to use row types is through Bike’s new “smart row types” feature. In a new row, type one of the following markdown inspired shortcuts–followed by a space:

# Heading
> Blockquote
``` Code Block
: Note
[], -[] Task List
[x], -[x] Task List (completed)
1. Ordered List
-, *, + Unordered List
--- Horizontal Rule

The shortcut text is replaced and the row type is set. Row types are supported in both .bike and .opml outlines. Learn more about row types in Bike’s user guide.

Full Changes:

  • Added Row types
  • Added Format > Row > Types
  • Added current row type to status bar
  • Added row type options to formatting pallet
  • Added scripting support for row types
  • Added text statistics for selected text
  • Added shortcuts automation support for row types
  • Added Spelling and Substations options to Edit menu
  • Moved autocorrect options to new settings panel
  • Added “Use smart links” autocorrect option
  • Checking and autocorrect options are now global
  • Checking options are in text checking panel
  • Reorganized menus, removing “Row” and adding “Go”
  • Changed selection drawing to only highlight text
  • Improved focus buttons spacing
  • Increase focus out button visibility
  • Fixed crash when pasting rtf text with CMYK colors
  • Fixed crash when selecting within font ligature
  • Fixed opening message links
  • Fixed invalid stylesheet caches

To get preview releases through Bike’s software update select: Bike > Preferences > General > Include “preview” releases.


Some things to try and think about:

  1. Should be able to set types using Format menu.
  2. Undo, Redo should work.
  3. Formatting should change for expected types, for example heading type has bold text
  4. For some types (such as quote, code) formatting is also applied to children.
  5. When you hit return the inserted type depends on editor state… for example if you are typing a task list and press return then a new task list item is inserted. Generally should work like a standard rich text editor.

Some types are “atom” types. Right now the only atom type is “Horizontal Rule”. In the future maybe attachments or other things will also be represented this way. An atom type is represented in the editor as a single character. If you type into an atom type it will turn that row into a body type.

Some types show a “decoration”. For example task rows show a checkbox. Unordered rows show a bullet. On the other hand heading rows don’t show a decoration.

Much is changeable at this point. Please give these things a try. Imagine how you might use them. Imagine what make them more useful.


Very happy with the model so far! Looks like a great start.

1 Like
  • This is great! I’m particularly excited about check-off-able checkboxes. Some quick random thoughts:
    • Making a task list beneath a regular item as its title, I noticed the spacing was a lot wider than I expected, so decided to keep the heading and items at the same level. But I think this means the checklist wouldn’t be collapsible into its title. (And even so, there’s a surprising (to me) amount of space between the :arrow_forward: and row icon, and the icons seem to be offset vertically from the row text and triangle icon too).
    • I noticed that “Show Checking” shows a large empty box that confused me for a moment. After I clicked the ? I understood that it’s supposed to show spelling suggestions, but I didn’t initially realize that because I went to the menu to turn on “Detect Links”. Maybe placeholder text could appear in the list box if empty?
    • It might be nice if eg. pressing [] turned it into a checkbox, ``` turned it into a code block. (Funny, as I typed this I noticed in the preview that Discourse turns [] into ).
    • It would be very nice if the code font had an x-width more comparable to regular text. I noticed this earlier with inline code, but it also feels like the code formatting has a pretty high horizontal expansion factor right now.

Also, this feels a bit funny (I highlighted the code and selected Format > Code Block):

If only the top-level item is a code block then the indentation is still a bit surprising (and would be even moreso for Python code):


Please give these things a try.

A really useful development – many thanks !

( Looking forward to experimenting with using these types in Pandoc )


Here’s what is happening:

Second image is Bike’s debug mode, so it’s drawing borders around each separate layer.

  1. Each row starts with a handle
  2. The handle width is how much the outline indents at each level
  3. If a row has a type decoration (checkbox) then that decoration is added after the handle.
  4. The type decoration width matches the handle width:
    • I think this is nice because in the above images it makes the x start positions of “Two” and “Three” match… otherwise it would create a ragged text edge.
    • I also think it also seems logical and looks “correct” with debug lines are drawn in.
    • I agree when the debug lines are not drawn it doesn’t look quite right.
    • Any thoughts on how to fix?
1 Like

I’ve just posted Bike 137 which changes the type decoration placement slightly. The above is still true … type decoration gets same exact width as handle, but type decoration is no longer centered in that space.

Instead the type decoration is now placed so that there’s equal white space between the leading handle mark and the start of the text. This change does mean that type decorations no longer line up perfectly with handles, but I think overall it looks much better.

1 Like

Hum, you are right that doesn’t quite work does it. I think the answer here is that code blocks should not have a type decoration. I’ll get that fixed tomorrow.

1 Like

Thrilled to have task rows. Thank you!

This is a thing you probably know about and will get to, but when a task item is checked, the text on that row is struck out. But if you uncheck the task (manually or via undo), the text remains struck out.


This may be a step too far into todo app land, but… I wonder about being able to automatically collapse all completed task items, and also a form of focus where completed task rows and their children are hidden.

Yes this is a styling bug. It should fix itself if you resize window, or focus/unfocus window.


I expect to follow a similar design to TaskPaper here.

I “think” the next big feature that I’ll add to Bike after this release is outline filtering. That will allow you to (among other things) show you a view of your outline with completed items hidden.

I’m not sure what you mean exactly by automatically collapse completed tasks. Generally I shy away from “automatically”. It should be pretty easy to write a script that would do this though.

1 Like

Thanks ! I like this representation:

<li id="U9" data-done="2023-07-09T21:29:23Z" data-type="task">

( time to change some of my scripts, and simply discard others, as no longer needed :slight_smile: )

I think I will keep things like this… but still figuring a little. Maybe type should be data-type to be HTML “the right way”. Or maybe data-done should be simplified to done to “clean things up!”. Thoughts and feedback welcome.

At the moment my thinking is data- attributes are the ones that I will also display as tags in some future release… but it would be easy enough to filter out the attributes that I don’t want to display as tags… so that data- scheme really isn’t needed.

I think there may be advantages in going for standards compliance where possible – to get the most from standard tools, for example, and as a kind of exercise in caution about the future.

  • data-done seems good
  • "type" once had an HTML role in input tags, now deprecated, so I suppose it’s arguably going spare, at least for the moment. ( My first instinct might be to go for data-type, unless that feels like too much of a file-size inflator )

Thanks, I think you are right… I’ll go for data-type in next release.


Thanks for the new version! I tried out task lists because I often use Bike for to do lists! Currently I use the ⇧⌘L and ⇧⌘- shortcuts to select then strike=through the line.

I think the main drawback to my workflow is that when the task list is marked as done, all of its children are struck through too. Personally I’ll write tasks like:

  • Q. Why is X broken?
    • A. I forgot to do Y.

When the whole thing is struck through, the “A.” line is harder to read. I could see why someone would want the whole tree to be struck through, though.

Also, this is a nit but I noticed the checkbox lines seem to have different thickness in the checked vs. unchecked state. I could also understand why someone would prefer this though.

Horizontal rules are nice! I’ve just been leaving blank lines to separate sections. For me I don’t think they add enough to be worth going into the menu to add them, but maybe I’ll set up a keyboard shortcut and get used to it. Code blocks are neat! One nit there is that the </> icon causes the indentation on the first line to match the indentation of the first child, which can make code indentation look a little weird.

Overall these all seem pretty nifty! Haven’t hit any weird undo/redo bugs yet. Also looking forward to images being added as a row type—at that point I think I can entirely use Bike instead of Obsidian for work notes that require images! Thanks for all the great work!

1 Like

Sorry but if I am the user from Mac App Store, is any way can let me use the pro features in preview version?

I may be missing something, but I think that the newly-added note row type may not yet have made it into the scripting SDEF.

(We can fetch the type properties of most rows, but evaluating that property for a row of type note is tripping an Apple Event error here).

macOS 13.4.1
Bike 1.13 Preview (138)

In the meanwhile, although we can’t yet set a note type by script, we can already write something like this to read the type:

// bikeRowTypeName :: Bike Row -> String
const bikeRowTypeName = row => {
    try {
        return row.type();
    } catch (e) {
        return "note";

Oops you are correct. I’ve just added it now, will be in next preview release.

1 Like