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 Mail.app message links
Fixed invalid stylesheet caches
To get preview releases through Bike’s software update select: Bike > Preferences > General > Include “preview” releases.
Formatting should change for expected types, for example heading type has bold text
For some types (such as quote, code) formatting is also applied to children.
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.
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 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):
Second image is Bike’s debug mode, so it’s drawing borders around each separate layer.
Each row starts with a handle
The handle width is how much the outline indents at each level
If a row has a type decoration (checkbox) then that decoration is added after the handle.
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.
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.
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.
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.
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.
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 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!