Thanks for the clarifying questions.

The files are all on a unix file system served over nfs, so everyone has
the same / root. the users (students) have read access to my files.

I am working towards creating "packages" of notes in org-mode (they might
even be installed as emacs packages) for the courses that I teach. Having
relative paths within a package certainly makes sense. I would like to link
to notes in other packages too, as the courses are related, and build on
each other. but I won't know in advance where those get installed. It
sounds like those packages will have to have some variables configured to
make that work out.

Thanks for the tips on tweaking link formats and id behavior!

j

On Thu, Jan 16, 2014 at 5:32 PM, Nick Dokos <ndokos@gmail.com> wrote:

> John Kitchin <jkitchin@andrew.cmu.edu> writes:
>
> > Hi all,
> >
> > I am using org-mode in a multiuser environment, (i.e. many people have
> access to the org-files). I create org-files with links in
> > them to other files, and I am trying to find the most robust way to do
> that.
> >
> > For example, in one file in section I type C-c l to store a link, and
> then later C-c-C-l to insert it in another file. That link
> > looks like this:
> >
> > [[file:~/dft-book/dft.org::*Introduction%20to%20DFT][Introduction to
> DFT]]
> >
> > It works for me, but not for other users, because of the ~ in it.
> >
>
> How do the other users have access to this file? Is it in a shared
> filesystem? Are *all* the files you want to share in a shared filesystem?
> Does everybody have write access or are they read-only?
>
> There is org-link-file-path-type which can be set to noabbrev to use
> links with absolute paths (without ~). That would work in a single
> namespace but not e.g. if everybody mounts some shared FS over NFS
> and uses a different mount point. Relative paths would work better
> in that case.
>
> > I have tried using org-id, with mixed results.  I set this up in my init
> file
> >
> > ;; automatically create ids for links
> > (require 'org-id)
> > (setq org-id-link-to-org-use-id 'create-if-interactive-and-no-custom-id)
> >
> > Now, when C-c l is typed, it creates a unique id in the heading, and the
> link looks like this:
> > [[id:065443d5-59d7-4119-b530-7b63af28349b][Background]]
> >
> > I haven't figured out a detail though. If the original file is not
> > open, org-mode does not seem to find it when I click on it.
> >
>
> In the same emacs process or a different one?
> I haven't seen this but the last time I used IDs was some years ago
> (but see below).
>
> > Am I missing some setup for org-id? I can see here
> > http://orgmode.org/worg/org-api/org-id-api.html that there is some
> > concept of a database of ids, but I didn't see anything about using
> > it.
> >
> > How would another user click on that id link and get to the file if they
> didn't have the database?
> >
>
> The id database is kept in a file:
>
> ,----
> | org-id-locations-file is a variable defined in `org-id.el'.
> | Its value is "~/.emacs.d/.org-id-locations"
> |
> | Documentation:
> | The file for remembering in which file an ID was defined.
> | This variable is only relevant when `org-id-track-globally' is set.
> |
> `----
>
> so it would have to be in a shared place for others to use. But it seems
> that writing this file out is racy. It can be made read-only of course
> but you would not be able to create new links.
>
> The problem is that as you create links the id locations are kept in a
> variable org-id-locations in memory. The value of the variable is saved
> to the file when emacs exits and when org-id-find is called and cannot
> find the id (I think), or you eval
>
>      (org-id-locations-save)
>
> explicitly.
>
> In particular, if the database file is up-to-date, then starting another
> emacs and following an id-link works whether the target file is already
> visited or not. Maybe what you are seeing is this discrepancy.
>
> > Finally, the end goal here is to package a set of interlinked
> > org-files that someone else would use as a standalone package. What is
> > the best link strategy for that?
>
> My guess would be relative file links: all the files are in the
> hieararchy under a single directory and all the file links are limited
> to point strictly within the hierarchy, using relative pathnames.
>
> Nick
>
>
>