I think most of the time it’s lossy open as whatever app’s specific feature set is. It’s rarely plain text, unless it’s a file format the app doesn’t recognise. Obsidian will ignore anything that’s not .md, iA Writer will open as plain text. But if you feed them .md files, they will render whatever they know and ignore the rest.
I think the closest analogy would be graphic editing apps that can edit AI/PSD files. Affinity and Pixelmator can open PSD/AI files regardless of origin and either a) on open, convert to proprietary format with various degrees of loss or b) edit PSD file directly, also with various degrees of loss. They either use own extension or do (possibly lossy) save back to PSD or AI. But unless you’re actively editing concrete file, the language around that is usually Export to... and Import , not Save and Open .
I agree import/export is the clean way to do this, but it’s also much less powerful in my mind. Then you can’t share a document between (for example) Bike and a markdown editor that only understand (.md). Instead you need to go through Bike export process each time.
Allow user to specify custom file extension in save panel by typing extension directly, ie myfile.md.
This should fix the original bug of things just not working. It should also make the settings panels easier to understand, custom file extensions is a rather specific need.
It makes it slightly harder for users to create a new file with a custom extension, but only typing extra .md.
On read of .md Bike will first try limited .bikemd format. If that content conforms to .bikemd then Bike will open as .bikemd, otherwise will open as plain text.
Am curious to know what the criteria for that distinction will be!
BTW, on narrower window sizes, would it make sense for Bike to shrink back to its previous size when you close the sidebar? Currently it expands the window to make room for sidebar, then resizes editor view to cover window size on close. Maybe there’s a setting for this I’m not seeing, or maybe that was Taskpaper…
Are those integer values anything that we need to understand ?
A separate, but related question – I am writing .bike files from a draft Pandoc bike-writer.lua, and in the interim just generating distinct id strings without trying to match the 21 character Bike ids.
I notice Bike conserving my id strings – unique within the doc, but fragile in a broader context and perhaps poorly suited to links.
Should I perhaps:
write no id= attribute at all – letting Bike generate one on first read, or
adopt some standard approach (or library function) to create a proper 21 character random string ?
e.g. perhaps this kind of thing:
import { nanoid } from 'nanoid';
// Generates a standard 21-character random Nano ID
const rowID = nanoid();
Good catch. I need to update the @id display in path editor. There are two sources for IDs. External ID’s (like in your search path) and internal ids which shouldn’t be accessible to extensions scripts. I’ll hide em!
It should be safe to use any id you choose. Links are scoped by outline-id (which is a UUID) and then local row id. So there isn’t a problem with collisions.
There is a potential issue with markdown documents:
Markdown documents try to keep markdown content looking clean by only including ids for rows with referenced ids or with custom set ids. That means if you custom set your ids then they will all be encoded into Markdown documents.
I think the best approach is to not write any id (let Bike generate them), unless you want to reference that id by name later. For example maybe you want your outline to have a few well known rows (such as archive, etc). Then you could provide ids for just those well known sections that you want to get back to later.
Hey @jessegrosjean, I’m having lots of random crashes in Bike 268. I think this is related to ==mark==. I have many marked text in my outline which has around 14000 words. In many cases I cannot scroll through the outline. Sometimes crash happens when I do not even scroll. I divided the outline in to 4 parts but still having crashes.
I have received very few crash reports and I don’t think any related to syntax highlighting.
It should be that you get prompted to send crash logs when you next start app after it crashes. (Assuming you have Settings > General > Prompt to Send crashes)
And actually you may have … but email didn’t match with your form email. I got two reports from “Darren”. Good news is I think underlying cause of those is fixed now.
And apologies if I should have a connection there in my brain already I pretty much only know forum handles, emails and human names are to much for my limited memory
Nice! I noticed that the Heading Levels extension doesn’t set the font scale as described in the README. I’ve added the needed code, but there’s likely a more elegant way to do it.
@zak Thanks, and sorry I didn’t notice that request before. Thought I was watching all those repos, but turns out I was not. Anyway, I’ve added a comment. I think scale is wrong approach for this, but I’ve shown how you can instead set font size.
I pretty much only know forum handles, emails and human names are to much for my limited memory