I’m using Bike as a plain-text editor, and sneaking some basic markdown (bold, italics, headers) into it.
Now, I know Bike has some support for less popular formats - OPML, RTF, Plain Text all supported, which I find useful and noble. But what throws me is that slinging asterisks around text, as I’d hope a ⌘B would do, pops up an error message telling me it knows what I want to do, but that I should be doing things in a different format.
Surely adding some basic support - even if it’s not previewed - would be worth adding? I have a number of text editors that respect that muscle memory and sling asterisks in there dutifully, and the friction when I’m in Bike throws me.
If you want to capture bold or italicised text from Bike in a Markdown asterisk pattern, then it may be more efficient to use a Copy As Markdown script – perhaps something (for Bike 1) like:
Or
Note also that Bike’s affinity cursor makes it very quick to start and end special formats.
What starts with ⌘B or ⌘I or ⌘⇧` etc. can be ended immediately with one tap of the right-arrow key (and the affinity cursor always shows (and can toggle on ← or → ) whether format application continues or ends at the current insertion point)
Thanks for the suggestion, @complexpoint. I see where you’re coming from; I’m not prepared to be all-in with a non-plain-text format first though, because my other tooling is built on Markdown as the source documents - which I usually disguise on disk as .txt. The friction of exporting, rather than mutually consuming the same documents, is an extra layer of something for me to mess up and lose track of.
I guess I will just have to imagine bold and italics and stick with plain text; this works as a baseline. Maybe (free time willing) there’s something in the theming I can look at.
There isn’t currently a way to do this using the editor style system. I think for now you are doing the best/simplest option for your plain text goals.
Possible enhancements using existing Bike 2:
Using Bike’s extension system one could implement Command-B to wrap the selection in **'s and also support other syntax shortcuts. You still wouldn’t see syntax highlighting, but it might make editing markdown easier. Potential problem is that you would only want these overrides in place when editing markdown outlines, not rich text… otherwise you would break rich text editing. I think possible to handle by looking at document fileType, but I haven’t actually tried to see if that would work.
Possible future enhancements using future Bike 2.x:
I do have eventual goals to support markdown as a serialization format for Bike outlines. In that case you would edit Bike outlines as rich text. But when you saved you would get a plaintext markdown file. Would that work for you? To me this is the most “Bike” like approach for solving this problem.
The extension system approach sounds quite sane; I’ll have a look into this when I get a chance, thanks.
As for the serialization format: this also sounds a very sensible approach. I’d imagine it would ultimately boil down to whether ⌘S saves the file back in place as the original format or not; for now, while I’m editing markdown-in-disguise text files, that seems to be the case, and absolutely what I’d expect; I find programmes that assume save means you want to export in a different format than was opened quarrelsome. Ideally it would keep shtum on saving, and only raise an notice should the user invoke functionality that would not survive being written out in the original format.
I’m not sure if this is the right thread or not, but I’m wondering if there are plans to add support for more markdown-to-styled-text formatting in Bike?
Currently, a few things work as expected, i.e.:
- starts an unordered list
1. starts a numbered list
- [ ] starts a task list
# starts a heading
However, I’m regularly noticing some syntax isn’t automatically detected. Notably:
Ho, this is very nice. Thanks, and well handled! I had a cursory shufty, repeatedly lying to Bike that this .txt file was actually .bikemd. I emboldened text, and it became visibly bold, and on saving (and having absolutely no friction whatsoever between hitting ⌘S and Bike doing the right, sane thing to the file on disk, anticipating my every hope in not asking me anything) found it had mapped the correct number of asterisks into the text file.
This is incredibly encouraging, I didn’t realise that something so mundane would end up being so satisfying! But to be able to play with all the other features of Bike, within a Markdown document, is fantastic. Really great to see where this is going.
The only downside now is I have to look into writing themes to set colours for the editor, but this is the price of progress. There could be worse prices. I guess I was on a much older release!
Hmm … weird. I do get bold, italics and code. However, it seems if I have an item highlighted plus italics then the italics don’t come across. Not a problem with bold and highlighting however.
Yeah, I’m seeing bold and italic too. Generally inline style element should all be fully supported in the standard way. Block level elements are more limited and non-standard in places to fit the outline model. Can you should an example where you are not getting bold, italic formatting?
Bike’s editor is still rich text only, you can’t type in markdown syntax.
The new markdown support is in the file format. So when using .bikemd as the file format if you create bold, italic in your document normally, then when you save it will be saved using markdown formatting. And when you reopen that formatting will be parsed back into rich text for Bike editing.
Ah, I think special casing highlight to <mark>, baseline to <sup> or <sub> was too clever. Instead I think I will just use inline attributes for any attribute not handled natively by the parser. (since inline attributes are handled by parser) So highlight would become: