Re: [O] most robust linking practices?

[John Kitchin]

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 <address@hidden> wrote:

John Kitchin <address@hidden> 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