Might it look possible, at some point, to support a Copy As Link for the current line ?
(For use within documents, and between)
Looking at the HTML spec Links in HTML documents the id elements of bike nodes would seem to lend themselves well to use as HTML fragment identifiers for links within documents, and to particular lines, from other documents.
Yes, I certainly want to take advantage of the ids to enable stable links, but I haven’t though much about the details. I guess you were thinking something like this (if not let me know, again I haven’t thought to much about this):
bike://file_path#item_id
Also each outline has a UUID, so this might also be an option:
bike://UUID#item_id
Assuming that Spotlight can index find the UUID. That would be nice since files could move and be renamed without breaking links… of course it also means if you duplicate a file then a link might point to two different documents, but I’m not sure that’s a huge problem if it’s exposed in UI.
File path option the most strait forward, but also gets a little complex unless everything limited to absolute paths, and of course they break all the time. Relative paths is better, but then stuff only breaks sometimes and it’s more confusing to explain. Or use both options … ehhh. Or more complex UUIDs with Spotlight?
I haven’t experimented deeply either, but a UUID approach seems to be working well in the DEVONthink case, where their Edit > Copy Item Link yields just a UUID for the location identifier.
x-devonthink-item://UUID
If it looks feasible, I think your second pattern there (document UUID with item ID) would be ideal:
bike://UUID#item_id
For links between nodes in the same document, I wonder if the UUID could be elided ?
(Interpreted as the local document by default, perhaps ?)
Covid entered our house for first time today so I’ve been a bit distracted, but I have been having fun messing with links. It’s working pretty well I think. Here are a few notes on design. Let me know if you see any big problems:
Links are of this form: bike://root_id#item_id
Thats very similar to above, except I’m not using UUID for root id anymore. They are just so long, and in practice I don’t think a shorter ID will make any difference… in particular because no mater how long I make ID’s someone can still just copy a Bike document, and then there will be duplicates. So all logic has to handle duplicates anyway. (It’s simple, when duplicates are found they are all opened)
Here’s what a link looks like: bike://3z-6qr_v#aF. The fragment can be left off to just link to document.
The link is resolved using Spotlight search… so links to a document will only work if document is already open, or if document is indexed by spotlight.
Also I’ve adjusted file format so head stores link as keyword. Spotlight doesn’t index HTML attributes, so that’s the best way that I could get root id indexed:
<head>
<meta name="keywords" content="3z-6qr_v" />
</head>
This change also fixes a bug where I don’t think Bike documents were getting spotlight indexed at all. Apparently spotlight doesn’t like documents that have empty <head/>.
I hope that all involved get well soon!
The link work sounds very promising – thank you !
Good luck with swift recoveries !
Just wondering if I need to tweak an XML parser (for custom export demos etc)
The <meta> content id is a copy of the root <ul> id ?
(or perhaps the root <ul> no longer carries an id ?)
But no hurry – I’ll discover in due course.
Keep well !!
No… and actually I think I’m changing approach to use extended file attributes instead. The keywords hack wasn’t working for opml, and of course also wouldn’t work for txt.
I think instead I will use extended file attributes … I had tried them originally, but that didn’t seem to work and so I went the keywords route. But now I’m setting the com.apple.metadata:kMDItemIdentifier extended attribute for all files when I save and that seems to work well. Also seems a bit more …appropriate than using a keyword.
The drawback with extended attributes is they can get removed. I don’t really know what all the different circumstances are that that can happen, but it’s possible. The fix will be to just resave the file from Bike to have the attribute added back.
Overall I think this is a cleaner solution.
Wow … that was quick … the path and UUID links to particular lines in Bike (Preview 23) files work well !
and with Ctrl-click, Open link, even from one line to another elsewhere in the same file …
That opens up a lot of things.
Thank you !
Glad works. I’m a little worried about relying on Spotlight to find the links, but has worked well so far for me.
I’ve used these links for a few days now. They’ve been very solid, and it’s a real delight to be able to link into (and between and within) fast and light-weight outlines.
Brilliant. Instant wiki, for one thing.