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