Re: Re: RELEASE: Org-mode 6.08a

[Carsten Dominik <dominik@uva.nl>]

Hi Samuel,


On Oct 7, 2008, at 11:36 AM, Samuel Wales wrote:

> Comments on the interesting attachment feature.
>
> 1.  This function needs "(interactive)", i think.
>
> (defun org-attach-open-in-emacs ()
>  "Open attachment, force opening in Emacs.
> See `org-attach-open'."
>  (org-attach-open 'in-emacs))

Indeed, I will fix this later today

>
>
> 2.  This is trivial to rebind, but my guess is that emacs types would
> prefer to open things in emacs using the nonshifted keys.  e.g. dired
> instead of file browser, emacs instead of text editor.

Not if it is a PDF or Word file or so, not you don't.  Opening  
attachments uses the exact same mechanism as following links with `C-c  
C-o'.  So the idea is (I should also mention this in the attachment  
section of the documentation), that you configure org-file-apps org  
one of he system-dependent variants to open certain file type with  
external applications, and others inside Emacs.  Then the normal  
opening of an attachment will always do "the right thing", and you can  
overrule this standard mechanism by using "O" instead of "o".

For example, the default setting in org-file-apps already opens .org  
and .txt files inside Emacs.

> 3.  I'm getting the idea that the attachment system is partly to avoid
> linking files?

Yes, I think so too.

> This is good because links are easy to break.  The key
> is to have a directory that is only for org, and to use the filesystem
> to identify the attachments.  Then there is no broken link to a file.
> I like the idea.
>
> The current implementation explicitly lists the attachments.  Perhaps
> they could be retrieved from the dir?

Yes, also a discussion point I had with John.  I think it is OK to  
have that list there so that you do not have to open the directory in  
order to see what you have, but things an get out of synch.  Use "z"  
to get them back into synch.  I will consider to use a live `directory- 
files' when it comes to selecting an attachment for opening.

> 4.  Another possibility, if we have a directory dedicated to a node,
> might be to inline the files under the node.  Each subnode would be
> the name of a file in the dir associated with the node.  The contents
> of the subnode are the contents of the file.  Then any editing of a
> headline would change the filename, and any editing of the contents
> would change the file contents.  Searching would find things in the
> contents.  Yet data are only stored in the files themselves, not in
> the org file.


Wild idea, too wild for me, inlining is a can of worms.....  I think  
it is better to export from org to files where needed.

HTH

- Carsten


>
>
> For what it's worth.