- Added Bike Markdown format (.bikemd)
- Added Edit > Copy > Copy as Bike Markdown
- Added to/from Markdown API
- Improved pasting links
Download:
2 Likes
Iāve had some new ideas on āmarkdownā and think I have a pretty good solution in this release.
First, Iāve long delayed markdown support in Bike because thereās no good mapping between Bike and the full markdown spec. Seems like it should be possible, but itās a mess of corner cases that donāt quite work. And without a full mapping it means Bike will either loose Markdown structure or its own outline structure when editing and saving Markdown.
This was frustrating, because there is a nice clean mapping between large parts of Bike and Markdown. Solution ā¦ why didnāt I think of this sooner ā¦ āBike Markdownā.
Itās a clean and simple mapping from Bikeās data model to something that is āmostlyā markdown.
Features:
- Looks and works like markdown, easy to send into Markdown based workflows
- Round trips through all Bike outline states in consistent way
- Does not store row attributes, ids, dates, etc, so not full replacement for .bike format
Compared to standard markdown some differences are:
- Leading whitespace is always used to structure outline (no 4 spaces for code)
- Leading # in a heading denotes that headingās outline depth
- No special container types, example: list canāt also contain header on same line
So now if you open a .md file in Bikeā¦ youāll just get the plain text of that file, because Bike doesnāt understand full markdownā¦ on the other hand if you open a .bikemd file then the markdown will be read into a Bike outline structure in a consistent way, and also written out in a consistent way.
Open to feedback on how to improve, or just bug reports.
4 Likes
Well shootā¦ in all the excitement I uploaded wrong Bike 246 ā¦ without markdown support. Iāve just fixed that downloadā¦ if you click the download link above you should now get correct version.
Thanks a million for these new options! Iāve been waiting for this for soooooo long. Glad itās now a part of Bike. Copy as Bike Markdown makes the transfer from outline to MD document in iA Writer or other apps a breeze ā¦ before it was a chore. I will now be using Bike a LOT more than previously. Really appreciate this.
2 Likes
This is great ā I like the encoding of increasingly nested Bike heading type rows in terms of increasing length of ### markup, and the inclusion of inline markup like <mark> <sub> <sup> etc.
Is there an asymmetry in this draftās implementation of strikethrough ?
- I notice that text flanked at each end by double tilde is correctly read in to
<s></s> - but on write out (Save As
bikemd, and Copy As), we seem to be getting only a single tilde at each end of thestruckstring, which apps like IAWriter donāt read as struck through.
This is great stuff! The fact that Bike outlines are now unlocked as markdown on iOS is a huge deal, especially since all the common stuff - lists, tasks headings, basic formatting, translates very nicely into most markdown editors.
One thing I notice, in addition to @complexpoint ās comment on strikethru is that when I use a code block row type, the .bikemd file will output:
```This is a code block
instead of
```
This is a code block
```
Because thereās no closing ``` it means that the remainder of the text in the document will be interpreted as a code block.
Conversely, a āproperā markdown codeblock will be read by Bike as Body text wrapped between two Code block row types:
func sayHello() -> String {
return(hello + boinkers)
}
Not sure what the correct approach here is. I think this is an acceptable limitation.
2 Likes
Iām using swift-markdown package for parse/write of the inline elements, and that seems to be its default behavior. Iām not sure if thereās a knob to change, I donāt see yet, but seems there must be some way.
1 Like
Hum, yeah code blocks are definitely a problem. I will change the ``` marker syntax or figure a way to add proper start/end wrapping.
Iām also now realizing that it wouldnāt be too hard to give the Markdown format full parity with Bikeās html format using custom inline and row attributes. The problem is syntax. Using swift-markdown I get custom inline attributes for free using this syntax:
Use swift-markdown ^[custom](attributes) inline attribute syntax
Unfortunately that seems similar, but a bit different to the syntax that pandoc uses [text]{attributes}. Any thoughts on why they went with this different syntax?
What should Bike use? Another option is maybe to use inline <span attributes>text</span>?
2 Likes
*scratches head*
Wouldnāt that make the .bikemd file parseable pretty much to just Bike?
I donāt think so, these ideas are already part of important markdown processing tools such as pandoc.
Also, this is just for custom attributes, for standard attributes such as bold, italic, links, heading, etc you get standard markdown. The problem is that Bikeās data model allows you to associate arbitrary keys/values with any row and with any span of text.
What Iām saying is that the markdown format can also store those custom attributes (which at the moment you can only add via programming API) too, and thus give Bikeās markdown format full parity with the HTML format.
As an example of what it would look like using pandoc syntax:
*normal emphasis syntax* world.
- one
- [normal link](www.hogbaysoftware.com)
- [requires custom attributes]{favorite=pizza}
And this row has row level custom attributes {#myid}
So first you only get these custom attributes if you construct/configure your outline in a way that requires them. And second they are standards of sorts used in other places. Though this is also the reasons why I went with HTML for Bikeās first format, there isnāt really many hard and fast standards for extending markdown.
Originally I suggested ^[custom](attributes) syntax because thatās what the swift-markdown parser supported, so I thought it was some sort of āstandardā. After searching around, I donāt see much use of it, but the pandoc syntax (or at least pandoc in general) does seem quite often used. So I think thatās what Iāll go with.
Feedback welcome 
Still trying to figure this all out.
1 Like
Sounds good ā the Pandoc approach does seem sensible middle ground,
and well plumbed into many other formats ā¦
Hereās a question:
Should I encode body row as list items (with a special marker) when they are indented? Otherwise markdown system sees them as code blocks. I guess I would use the + for this. And when parsing would detect that marker and parse as a body type row, not an unordered list. I think this probably makes sense, but feedback welcome.
Iām trying to handle this case in Bike:
one
two
And proposing it is encoded as:
(normal Bike unordered rows would be encoded using - marker)
+ one
+ two
I think I follow, but thereās still a lot I donāt understand about what the final .bikemd file would show-this is where it gets a little too technical for me.
I guess what I was going for is to avoid having the .bikemd be āpollutedā by data that doesnāt make sense when youāre reading it in other plain-text/md editors. Iād gladly sacrifice some data fidelity to gain interoperability with other platforms, particularly iOS/iPadOS, without having to resort to document conversion first; but I also understand others might want more granular parity.
I suppose you could, but then again, something like this will also be rendered as a code block. Not sure it makes sense to handle all these cases?
Itās also a hard to track moving target hereā¦ very much still a work in progress.
I think there are a few use cases, and this is a very important one that I think will work well.
The thing to know is āallā these additions of inline attribute syntax, block attribute syntax, etc ā¦ they only āactivateā when you use them. Outlines that just use standard markdown formatting wonāt see them at all.
One big change that Iām making for the next release is I will always encode your full outline as a markdown list. This simplifies many things and removes some file format bugs that made it impossible to save all the outline state correctly.
So in the next version every non empty line will start with a +, -, or number. This makes an easy and direct mapping between Bike and Markdown. It also gets rid of all the (looks like code to markdown) syntax problems.
I liked the flattening of header idea, but it became too complex, and introduced some cases were outline information would be lost on saveā¦ (the last header in your outline would grab all trailing children no matter indentation level)
Export to flattened Markdown document is a future task sometime down the road.
Last, I expect an optional āfront matterā block that can be used to configure what custom attributes Bike saves in bikemd. For example I donāt expect it to save all ids or created and modified information by default. But if you do want to also save that using custom attributes, youāll be able to turn that on by adding a front matter block saying you want it.
Hope that makes some sense.
1 Like
It does! And I hope you know youāre headed for Logseq MD territory, so expect an influx of users! 
Oh, thanks for reference, Iāve played with Logseq, but never really thought about file format. They seem to have a good syntax for codeblocks! Iāll see if I can use that too.
1 Like
Thanks @jessegrosjean - the new Markdown support will be very very helpful!
A few quick notes from testing:
-
Currently, saving as
.bikemdworks fine, but.bikemdfiles are only recognized on macOS - no Markdown/plaintext editor can open them on iOS. -
Manually changing
.bikemdā.mdallows editing on iOS, but Bike then no longer recognizes the file as a valid.bikemd. -
A possible workaround could be using frontmatter metadata to tell Bike itās a
.bikemdfile, regardless of extension.
Would love to hear your thoughts on whether this approach could work or if another solution is planned.
EDIT:
I did not notice that Bike had a specific setting for the extension, so after changing the extension to .mdin Bikeās settings, I can now open the file on iOS.
EDIT 2:
Changing the extension to .md through Bikeās setting breaks the formatting in Bike, so I guess only solution is to stick with .bikemd for now
Unfortunately that seems similar, but a bit different to the syntax that pandoc uses [text]{attributes}. Any thoughts on why they went with this different syntax?
What should Bike use? Another option is maybe to use inline text?
Here is where the mess really starts. Of course, if you choose one āflavourā of markdown, the other people that uses other flavours will be unhappy.
Leaving apart the markdown mess and the lack of sanity in every attempt to make a ānew flavourā, I would suggest to follow the specification of pandoc.
The majority of the markdown editors follows the so-called mmd (or MultiMarkdown), because the compiler is ācompleteā and small (< 2mb), so they can embeed it and export the result for a lot of formats. But the point is that they use .mmd as a background to offer export options (epub, opml, html) for fairly simple documents. The huge downside of mmd is that they treat all apparatus in the same way, for example: footnotes and citation are virtually put in the same way:
Here a citation [see][@citekey]
[@citekey]: Bibliography
Here a footnote[^1]
[^1]: Footnote
The support for anything extra than the very basic markdown is rudimentary and not easy to automate. Basically, everything needs to be declared verbatim. Otherwise, you do not get the appropriated final result.
If we think in terms of processing markdown, as I suggested, then following the pandoc flavour will enable much more customization and easy to use for different workflows. Because, for sure, pandoc is years-light above any other markdown compiler, it is not even comparable.
EDIT: It is important to notice that cross-references and other things more advanced are not well structured in other markdown flavours as it is in pandoc. To be honest, pandoc take a lot of inpiration from .rst do develop the extra attribute declaration. In this case, I think that pandoc is the winner again (by huge margin).
Last, I expect an optional āfront matterā block that can be used to configure what custom attributes Bike saves in bikemd. For example I donāt expect it to save all ids or created and modified information by default. But if you do want to also save that using custom attributes, youāll be able to turn that on by adding a front matter block saying you want it.
This would be a killer feature! I give 10+ upvotes for this!
2 Likes