> I a sense, that shows that having a proper GUID system will only be > useful in case there are many tasks with the same name, which should > already be discouraged since headlines may show up in the agenda buffer > with no context at all.
I rarely have issues with conflicts in agenda. I use discreet files for separate projects, and unique subitems are scheduled. Otherwise I'll deal with duplicates. ;] > > IMO, a better rationale behind GUID is that headlines can change and > thus not be reached anymore by a search string. Having a GUID would > fix this. But I'm definitely not a GUID-fan, sorry :) I'm not a fan either, but recognize that it is a fast fix. You can use a static property and simplified search (vs regexp) and know that you've matched the correct item. That being said, perhaps the GUID should be dynamic and similar to the links interface. By default, no items have properties, or GUID's. If you trigger a "save location", a GUID is added to the current item adding a property drawer as needed. You can then choose that TODO from a list when creating the dependency (again, just like links). Thats what came to mind for me. ------------------------------------------------------------------ Russell Adams [EMAIL PROTECTED] PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint: 1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3 _______________________________________________ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
