What mechanisms will break Agenda links? Is it just moving notes to another project? Or are there other operations that will change the UUID / break the links? I’d just like to know so I can avoid those as much as possible for the time being. Linking is important to me, and I’d rather have less flexible notes / have to create “redirect” notes rather than have links break on me.
Also, does Agenda assign random UUIDs for each note, or does it somehow generate them so that a UUID could be reused down the road? I’m thinking that I can paste a note’s UUID into itself, so that even if the UUID changes from a move, I can still search for the UUID from now-broken links. But, that only works if Agenda picks random UUIDs as opposed potentially reproducing them based on some algorithm.
That’s indeed the only condition under which it breaks. It’s because each project is its own data store and upon moving a note from one project to another it effectively creates a copy in the target project and this copy gets its own (random) uuid. I’m afraid there’s no simple solution until we add mechanisms that allows agenda to resolve an “old” uuid to the new one in the new project.
Yes I know, this may invite a TL;DR reaction, but I implore you to read on … please.
Please forgive any presumptuousness on my part to even suggest the following. It harks back to the days when the use of handles were the bread and butter when coding on the Mac. It’s probably not necessary to go the full Hungarian these days.
Handles can suffer from performance issues as there’s an extra ‘hop’ to get to the thing you want. It depends on how much of a hit it translates to in the Agenda environment… I’m not sure if there’s a twist on the use of handles with the suggestion, but it could save a major restructuring/refactoring/recoding effort. Here ‘tis:
In this case, the handle is the global invariant (permalink, UUID, <insert_your_favourite_term>);
Create a single, global table (OK, database), where each record has two fields, namely a UUID (the handle) and its associated “Agenda-Link”;
Both fields would quite likely be indexed/keyed, enabling searches for both (this table will hopefully not be referred to as a graveyard);
Whenever/before an “Agenda-Link” MAC (move/add/change) for a note occurs, look up the graveyard (D’oh! ) for a hit on its current link (I guess there wouldn’t be one if it’s a new note);
If there is a hit, update its entry with the new one;
If this is a new note, add a new record with its link, along with a new UUID/permalink value;
Add a UUID/permalink offering in the “Copy as …” pop up, or better yet …
Depending on whether people are heavily using the current offering ( direct “Agenda Link” to the note, which goes stale as soon as it moves into another project), you may add a little advisory to the original ”Copy as … Agenda Link” that it may soon be disappearing. This could also happen silently (I prefer surreptitiously), by combining the two or even getting rid of the original as an export;
You could find out how heavily the current offering is being used (it’s the only one right now), by referring to the global table anyway - distinguishing the lookup by its key (say agenda://note… vs agenda://uuid), although that may break a few things as every instance of the application would need to have its current pointers added to the graveyard;
Given the immediately above, it would perhaps be easier to (silently) change the “Copy as …” offering to the respective UUID/permalink and treat lookups for “agenda::/note/…” as you currently do, with one extra step. After determining whether the lookup is valid (it may have moved or been deleted) - check whether there’s a hit in the graveyard. If not, add a new record, as described above;
As I said, the presumptuous suggestion would likely not need a major overhaul of how things are presently stored. As to a performance hit, given the application (Agenda) and the use of its links are typically used in an interactive environment, the extra hop may not be that noticeable. I could be wrong.
Aside from obviating a major overhaul, another nice thing about this is the implementation would become more ‘hidden’ in time. And yes, it invites a seamless transition to the user base (important).
I’m sorry if this comes across as being rude in any way. That was never my intention. FYI - I’ve bitten the bullet and purchased DEVONthink, using Agenda for the ‘seagull’ view and DEVON as the detail (the nitty-gritty that move across projects). Using an expensive elephant as a bandaid is not my idea of fun. I prefer Agenda’s more ‘intimate/personal’ nature, but it currently doesn’t work (for me).
I wonder how many find really good value in the current “Copy as … Agenda Link” offering(?). I personally can’t imagine there being a huge fan base.
You’ve pretty much described what was always the plan
No, we don’t think it’s all too complicated, nor that there’s any performance issue too worry about, it’s just the sheer scarcity of time needed to bring it in place that is at play, as usual…
Not exactly sure what you mean with this, I’d argue that the majority of our users don’t move a lot of notes from one project to the other, and will therefore hardly ever hit the issue of a breaking link. For example I’m a heavy Agenda user myself but have perhaps done so a handful of time at most. So it really depends a lot on your workflow, whether you a) create Agenda links to many notes, and b) whether you often move notes from one project to the other. Again, we will fix this as it should be fixed, but it’s not that it prevents the current Copy As Agenda link from being useful in practise to the overall majority of users already.
Well, that’s kind of a self-reinforcing position to take. I don’t use links and move notes, because doing so breaks the links. If I could, I would.
My workflow is based heavily around moving things around (“refactoring” my notes). I’ll add a note to my inbox project. At some point that note grows, and becomes its own project (the note being pinned at the top of the project). And then it becomes its own category (originbal note being pinned at the top of the top project in the category).
Anyway, there’s no need for me to belabor the point. And yes, links are still useful – but I would say the value is greatly diminished by this constraint.
If memory serves me well, it took me no more than around a couple of hours after downloading Agenda to work out that the links break when moving a note around various projects.
Most of that time was me saying to myself “What am I doing wrong for this not to work?”. It was only when I copied and pasted the “before and after” move links into Apple’s Notes App to compare them that I realised - no, I’m not holding it wrong.
Disappointing. The primary reason for purchasing Agenda was a (now misguided) assumption that their links were unique and immutable no matter where notes travelled.
There was indeed a post going back to January that raised this shortcoming, by @viktor.lakics (I only discovered that after my post here), who also felt this was a high priority requirement. In his words:
My personal plea (again) is to … Please …raise the priority of fixing this. I feel there are more than just a handful who are disappointed in this constraint, to the point of either being tempted to dump Agenda or resign to the notion that - yet again - an App’s constraints changes a user’s behaviour (and ‘requirements’).
I would (again personally) rate fixing this higher than (say) work on:
The handwriting recognition feature on a surface that presently is an abject cognitive and tactile failure. What would be really cooler than hopping onto this questionable bandwagon (again - a personal opinion after many disappointments elsewhere) is to greatly improve upon an App like “Pen to Print” that takes images of handwriting and converts them into text for consumption into Agenda.
But this thread (and digression) is just me. Or is it?
Sorry guys, 2 people in a garage means by definition disagreement on any kind of priority we pick, it’s certainly high up on the list, that’s all we can guarantee at this point.
I’m another heavy link user. So far, this hasn’t bit me yet, since I rarely move notes around. However, when I saw this thread, I was nearly dumbfounded that the links would break if a note was moved.
I use links both within Agenda and from Omnifocus to Agenda (and from Agenda to Omnifocus occasionally). I often don’t use the name of the note in the text with the link either, so if it wasn’t for the fact that the notes are often on the same day, I could have a very hard time finding the note I originally linked.
I used to write Lisp software, so links are almost second nature to me.
So, I am also asking for making this a high priority. Thanks!
I can imagine that from a customer perspective this would seem an odd omission. It arises out of very technical aspects of our syncing data model. There is a clear path to fixing it, but we need to find some time between other high-priority projects to get to it. Stay tuned.
Yeah, absolutely true. And I’m not sure we would necessarily choose to do it differently were we to start again. The model we chose, like any of them, has pros and cons. The pros are mostly in the way things work for sync, and will scale in the future to collaboration. These are very valuable aspects. Downside is we have to work a bit harder on cross linking, but we will get there. Just a question of finding time.
Uh, ya think. I write quick notes to a Scratch Pad Project using a Shortcut. Often they aren’t deleted but moved, not to necessarily be looked at for a couple days until it pops up in Reminders. But if I had a link, it would break, rendering the process useless. Now I know what happened. Here’s my vote to move this feature to the top of the request pile.
I write my quick notes to a diary note for the day, when I go back and review my day later, some of those quick notes are ones I might want to elaborate on then. For each of those, I usually copy out and create a new note in the proper project and all. I just leave a phrase or short sentence in the diary and create a link to the detailed note. Since the detailed note is created where it belongs, the links to it work. That turns out to be a work around for this particular problem, more or less by accident since I’ve been doing this for months – long before I was aware of this issue.
I can imagine situations where you want to link to the note sooner rather than later. For example, if I wanted to create an Omnifocus task with a link to the note. A workaround would be to link the task to the diary to start with. Later, when I used the link there, I’d find the diary note and skim to the link for the detailed note. I could then update the link in Omnifocus so I’d go to the detailed note directly.
Not ideal, but doable and is mostly what I’m doing already. It helps that my diary notes tend to be short, mostly because if I have much to say about something, I go ahead and make a separate note in the proper project.
Quick Update: we’ve just added the necessary underpinnings that ensure that (newly created) Agenda links will continue to resolve also after a note is moved to a different project. Note that this will be part of the update after the iOS13 and iPadOS updates are out because those are already submitted and pending Apple’s releases.
What about the timing of a MacOS update to similarly align with the iOS and iPadOS fixes?
Ahh… thank you. I took a more negative perspective/interpretation, in that I assumed already existing links would still break if their respective Notes went walkies. This is good(er) news.
) for a hit on its current link (I guess there wouldn’t be one if it’s a new note);
