Re: [O] Fwd: Mac OS Alias file links
Hi Ken, Ken Mankoff mank...@gmail.com writes: http://article.gmane.org/gmane.emacs.orgmode/84707 appears blank The article is displayed correctly for me, probably a temporary issue with gmane.org. so perhaps the no reply is due to a posting issue. Hence, I send the email again... I don't use MacOSX so it's hard to know where to start. 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. Best, -- Bastien
Re: [O] Fwd: Mac OS Alias file links
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.
Re: [O] Fwd: Mac OS Alias file links
Ken Mankoff mank...@gmail.com writes:
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.
What does emacs do when you C-x C-f an alias?
If it opens it properly (i.e. opens the target file) then why is
anything needed in org? It seems to me that a file: link should just
work.
If it does not, then maybe that's where the capability should be added.
Org seems to be the wrong place for it.
But note that everything I know about aliases, I learnt in the last five
minutes, so I could be way off the mark.
--
Nick
Re: [O] Fwd: Mac OS Alias file links
On 2014-04-14 at 08:42, Nick Dokos wrote: What does emacs do when you C-x C-f an alias? Alias in OS X (and Shortcut in Windows) present as files. Org treats it just as it should - as a file. Everything works. If it opens it properly (i.e. opens the target file) then why is anything needed in org? It seems to me that a file: link should just work. If it does not, then maybe that's where the capability should be added. Org seems to be the wrong place for it. But note that everything I know about aliases, I learnt in the last five minutes, so I could be way off the mark. This requires me to 1) manually make an alias (something I never do), 2) choose where to store that alias on disk, and then 3) link to the alias in Org. Worse, the situation is not improved or difference since if the alias moves, the Org link (to the alias) is broken. I'm imagining the alias never exists on disk. Just as a representation inside Org, and pointing to the target file. Now the link can never break, unless the target is deleted. And there is no additional effort on our part beyond the existing work to make a link. -k. P.S. How does one make a link to a folder or directory in org?
Re: [O] Fwd: Mac OS Alias file links
Ken Mankoff writes: 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. If I understand correctly, this only works through Finder and not from a shell and POSIX file access functions. Whether or not Emacs could use aliases therefore depends on what interface it is using to access files on MacOS (I have no idea). I just checked in a VM and Windows Shortcuts also behave this way. No, they don't. Explorer does find the file if you move it into a subfolder and will ask you to tell it where it went if it doesn't find it, but any direct access through that shortcut will fail as if the file didn't exist. Also, WIndows shortcuts and Windows links are two totally different things and links don't follow moving targets either. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
Re: [O] Fwd: Mac OS Alias file links
On 2014-04-14 at 12:26, Achim Gratz wrote: Ken Mankoff writes: 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. If I understand correctly, this only works through Finder and not from a shell and POSIXfile access functions. Whether or not Emacs could use aliases therefore depends on what interface it is using to access files on MacOS (I have no idea). When you say this only works I'm not sure what you are referring to. I assume creation and/or access. * Creation Yes creating Aliases is a Finder function, although creation can be scripted from the shell through the osascript CLI utility provided on OSX. * Access Some access works through the shell. If I make a link to an alias in Org, opening the link works and is handled by the system for all the different types of files I can create an alias to. But an alias is not like an ln-like link. It presents to the OS as its own file, so if you try to edit an alias to a plain text file, you get a bunch of garbage (the alias), not the plain text file. In my fantasy, the link wouldn't be to an alias file, it would *contain the alias* the way the BibDesk field does. Therefore C-o on an alias: link would require extra code: Decode the alias, then pass it off to the system. I just checked in a VM and Windows Shortcuts also behave this way. No, they don't. Explorer does find the file if you move it into a subfolder and will ask you to tell it where it went if it doesn't find it, but any direct access through that shortcut will fail as if the file didn't exist. Also, WIndows shortcuts and Windows links are two totally different things and links don't follow moving targets either. My system is different. I'm not sure why. I have an XP VM. I created a New Text Document file on the desktop. I right-click, and select Create Shortcut. I have a new shortcut on the desktop. I moved the original file elsewhere (C:\, My Documents, etc. not just subfolders), double-clicked on the shortcut (still on Desktop), and the original file opened. I could edit and save it and saves were placed into the relocated file. If direct access you mean POSIX-level access, then perhaps. I don't know. But I think emacs can operate on files at a higher level. -k.
Re: [O] Fwd: Mac OS Alias file links
Ken Mankoff mankoff at gmail.com writes: On 2014-04-14 at 12:26, Achim Gratz wrote: Ken Mankoff writes: 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. [...] In my fantasy, the link wouldn't be to an alias file, it would *contain the alias* the way the BibDesk field does. Therefore C-o on an alias: link would require extra code: Decode the alias, then pass it off to the system. The point of using an alias rather than a filename or the name of a symbolic link that points to the file is that it inherits the property of Mac OS X aliases that moving the file does not break the alias --- it still points to file. For this to work as you fantasize, you would need to enable the Finder application to modify the part of the *.org file that encodes the alias when you change the location of the aliased file just as the Finder does to the alias when the location of the aliased file is modified in the Finder. That is a heavy lift. OTOH, writing an AppleScript to make an alias in a folder that is never moved, writing elisp to call that script and then make an org-mode link to the alias just created might work for you. HTH, Chuck
Re: [O] Fwd: Mac OS Alias file links
On 2014-04-14 at 13:42, Charles Berry wrote: The point of using an alias rather than a filename or the name of a symbolic link that points to the file is that it inherits the property of Mac OS X aliases that moving the file does not break the alias --- it still points to file. Exactly! For this to work as you fantasize, you would need to enable the Finder application to modify the part of the *.org file that encodes the alias when you change the location of the aliased file just as the Finder does to the alias when the location of the aliased file is modified in the Finder. I don't think so. I'm not sure how BibDesk handles it, but my BibTeX file is not modified when I move the PDF that is linked to an entry via that 1200 character field that encodes the alias. Clearly BibDesk does something neat to encode and decode that field, but once created, the OS nor Finder know anything about that line or the file containing it. I don't think Finder would need to know about a string in an Org file either. OTOH, writing an AppleScript to make an alias in a folder that is never moved, writing elisp to call that script and then make an org-mode link to the alias just created might work for you. Yes this would work too as a hack. -k.
Re: [O] Fwd: Mac OS Alias file links
On Apr 14, 2014, at 12:36 PM, Ken Mankoff mank...@gmail.com wrote:
On 2014-04-14 at 13:42, Charles Berry wrote:
For this to work as you fantasize, you would need to enable the Finder
application to modify the part of the *.org file that encodes the
alias when you change the location of the aliased file just as the
Finder does to the alias when the location of the aliased file is
modified in the Finder.
I don't think so. I'm not sure how BibDesk handles it, but my BibTeX
file is not modified when I move the PDF that is linked to an entry via
that 1200 character field that encodes the alias. Clearly BibDesk does
something neat to encode and decode that field, but once created, the OS
nor Finder know anything about that line or the file containing it. I
don't think Finder would need to know about a string in an Org file
either.
We can look at a BibDesk file to see how it works. It adds a special field
like:
Bdsk-File-1 = {YnBsaXN0MDDUA...AAAMO}
We guess that this base64 encoded, so we decode it (M-x base64-decode-region)
This then gives us a binary plist (it starts with bplist) which we can turn
into a readable form with M-: plutil -convert xml1 -o - - RET
This gives an xml representation of what BibDesk stores. It’s an archived
object of some kind, but I don’t know about OS X aliases to know what is the
important part--I presume the NS.data portion. It probably wouldn’t be too
hard to borrow the code from BibDesk and extend Emacs to do the same thing, or
write an external script. I’m not sure whether it would be possible to do it
without touching C/Obj-C. I would be interested in using such a thing (in
BibDesk .bib files actually), though probably not in writing it. :-)
-Ivan
Re: [O] Fwd: Mac OS Alias file links
On Mon, 14 Apr 2014, Ivan Andrus wrote:
On Apr 14, 2014, at 12:36 PM, Ken Mankoff mank...@gmail.com wrote:
On 2014-04-14 at 13:42, Charles Berry wrote:
For this to work as you fantasize, you would need to enable the Finder
application to modify the part of the *.org file that encodes the
alias when you change the location of the aliased file just as the
Finder does to the alias when the location of the aliased file is
modified in the Finder.
I don't think so. I'm not sure how BibDesk handles it, but my BibTeX
file is not modified when I move the PDF that is linked to an entry via
that 1200 character field that encodes the alias. Clearly BibDesk does
something neat to encode and decode that field, but once created, the OS
nor Finder know anything about that line or the file containing it. I
don't think Finder would need to know about a string in an Org file
either.
We can look at a BibDesk file to see how it works. It adds a special field
like:
Bdsk-File-1 = {YnBsaXN0MDDUA...AAAMO}
We guess that this base64 encoded, so we decode it (M-x
base64-decode-region) This then gives us a binary plist (it starts with
bplist) which we can turn into a readable form with M-: plutil -convert
xml1 -o - - RET
Or copy it and run
pbpaste | base64 -D | plutil -p -
in the shell.
This gives an xml representation of what BibDesk stores.
BibDesk has an archive of entries typically stored at
~/Library/Caches/Metadata/edu.ucsd.cs.mmccrack.bibdesk/*.bdskcache
and the 'NS.data' element of Bdsk-File-1 seems to point to one element.
The *.bdskcache file has a bplist and I guess the 'FileAlias' component
is what points to the pdf or whatever.
The relevant source for the alias itself seems to be here:
http://sourceforge.net/p/bibdesk/svn/19370/tree//trunk/bibdesk/BDSKAlias.m
but I do not do objective C nor CoreFoundation.h, which I think is where
the alias stuff lives now.
I think it would be necessary for one to have a good handle on
the stuff in CoreFoundation.h to make sense of this.
It’s an
archived object of some kind, but I don’t know about OS X aliases to
know what is the important part--I presume the NS.data portion. It
probably wouldn’t be too hard to borrow the code from BibDesk and extend
Emacs to do the same thing, or write an external script. I’m not sure
whether it would be possible to do it without touching C/Obj-C. I would
be interested in using such a thing (in BibDesk .bib files actually),
though probably not in writing it. :-)
One approach that sidesteps having to know the CoreFoundation.h stuff is
to use the BibDesk AppleScript capabilities. There is a model for this at
http://www.jonathansick.ca/adsbibdesk/
written in python, FWIW.
HTH,
Chuck
Re: [O] Fwd: Mac OS Alias file links
On 2014-04-14 at 20:21, Charles C. Berry wrote: BibDesk has an archive of entries typically stored at ~/Library/Caches/Metadata/edu.ucsd.cs.mmccrack.bibdesk/*.bdskcache and the 'NS.data' element of Bdsk-File-1 seems to point to one element. The *.bdskcache file has a bplist and I guess the 'FileAlias' component is what points to the pdf or whatever. Aha! I think this is essentially what you described in your last email when you said, OTOH, writing an AppleScript to make an alias in a folder that is never moved, writing elisp to call that script and then make an org-mode link to the alias just created might work for you. I guess that is how it is done. I think I can figure out how to do this much in elisp + a system language. The elisp side will be a good learning project. One approach that sidesteps having to know the CoreFoundation.h stuff is to use the BibDesk AppleScript capabilities. There is a model for this at http://www.jonathansick.ca/adsbibdesk/ written in python, FWIW. Yes. The AppKit module is a nice interface from Python to the OSX system. I think I will likely write the non-emacs code using this, or AppleScript or Automator directly. -k.
