emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Fwd: Mac OS Alias file links


From: Ken Mankoff
Subject: Re: [O] Fwd: Mac OS Alias file links
Date: Mon, 14 Apr 2014 07:32:40 -0400
User-agent: mu4e 0.9.9.5; emacs 24.3.1

Hi Bastien,

Thanks for letting me know it displays properly and email received. The
URL works for me this morning too.

On 2014-04-14 at 05:22, Bastien wrote:
> Even for those who uses MacOSX, you should perhaps be more specific
> on how Org-mode would store such links, then somebody might step up.

Aliases are a type of links ("ln" on linux, "shortcut" on Windows
"alias" on OS X (OS X of course also supports "ln")). The difference
between an OS X alias and "ln" is that if the target is moved, the OS X
alias still points to it, and double-clicking on an alias (or issuing
the "open" command in a terminal) will open the target, wherever it
is. I just checked in a VM and Windows Shortcuts also behave this way.

Therefore, if in addition to "file:" there were an "alias:" option, Org
could link to files that move. I think this is a powerful feature. I
imagine "alias:" would be an option when I press C-cl, and a way to set
it as the default when I press C-ucl.

That is, links would be [[alias:foo][FileName]] where "foo" is a string
version (hashed?) of the alias.

In BibDesk, "foo" is ~1200 characters long, and according to the BibDesk
documentation, that ~1200 characters is:

> The Bdsk-File entries store Mac OS aliases, which contain a file ID
> and absolute path. Bdsk-File entries also store a relative path, which
> is used if the alias is broken.

So it looks like an Alias can be hashed some way and stored as just a
string. An example BibDesk entry in by BibTeX file looks like:

@article{citekey,
        Author = {Someone},
        Journal = {Nature},
        Pages = {24--42},
        Title = {{A Paper}},
        Bdsk-File-1 = {YnBsa...etc for 1200 characters...}}

Opening the file with C-o would involve un-hashing it, and then treating
it the same way a "file:" is opened.

I imagine Org would mostly store the links the same way it stores file
links. The change would be that since the link is the alias (long ugly
string), the description would be required, and perhaps default to
/path/to/filename. Although since the whole point is that the /path/to/
can change, perhaps the default name would just be filename.

  -k.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]