Bug (?) adding attachment to note in remember buffer

Bug (?) adding attachment to note in remember buffer

[Robert Goldman]

When I try to add an attachment to a note in the remember buffer, I get
an error that looks like this:

Debugger entered--Lisp error: (wrong-type-argument arrayp nil)
  file-truename(nil)
  byte-code(xxxxx [org-id-locations list locs file id nil file-truename
throw exit t] 3)
  org-id-add-location("xvsc3fr01ge0@sift.info" nil)
  org-id-get(353 t)
  org-attach-dir(t)
  org-attach-attach("~/Desktop/hold-notification.eml" nil)
  call-interactively(org-attach-attach)
  org-attach()
  call-interactively(org-attach)

[sorry about the byte-code-garble]

This is on the latest version, pulled from git this morning.

Clearly what's wrong is the call to org-id-add-location with NIL as the
FILE argument.  That's the proximal cause.  The root cause seems to be
that when we call (buffer-file-name (buffer-base-buffer)) inside a
buffer created by org-remember, it returns nil (buffer-base-buffer is nil).

This suggests that the org-attachment code needs a special way of
handling attachment placement when it's invoked inside remember.

A short-term fix might be to use advice to intercept calls to org-attach
when invoked inside a remember buffer and have it raise an error and
tell you to wait until the remember note has been filed before adding an
attachment.

[as an aside, this whole mess is caused because I have no way to create
an org link to an email from Thunderbird, so I have to handle all my
email-related tasks through attachments.  Grrrr....]

An alternative would be to have org-id-get handle remember buffers
specially.  org-remember has some default location for putting its new
item, and that could presumably be looked up.  However, given that one
has the possibility of changing the destination of the note, this would
have to be handled carefully.  If (a) org-refile handles relocating
attachments correctly and (b) the code in org-remember for handling,
e.g., C-1 C-c C-c. uses the org-refile code; then this should be
relatively easy to handle.

Best,
Robert

Re: Bug (?) adding attachment to note in remember buffer

[Carsten Dominik]

Fixed, thank for the report.

- Carsten

On Nov 17, 2008, at 5:20 PM, Robert Goldman wrote:

> When I try to add an attachment to a note in the remember buffer, I  
> get
> an error that looks like this:
>
> Debugger entered--Lisp error: (wrong-type-argument arrayp nil)
>  file-truename(nil)
>  byte-code(xxxxx [org-id-locations list locs file id nil file-truename
> throw exit t] 3)
>  org-id-add-location("xvsc3fr01ge0@sift.info" nil)
>  org-id-get(353 t)
>  org-attach-dir(t)
>  org-attach-attach("~/Desktop/hold-notification.eml" nil)
>  call-interactively(org-attach-attach)
>  org-attach()
>  call-interactively(org-attach)
>
> [sorry about the byte-code-garble]
>
> This is on the latest version, pulled from git this morning.
>
> Clearly what's wrong is the call to org-id-add-location with NIL as  
> the
> FILE argument.  That's the proximal cause.  The root cause seems to be
> that when we call (buffer-file-name (buffer-base-buffer)) inside a
> buffer created by org-remember, it returns nil (buffer-base-buffer  
> is nil).
>
> This suggests that the org-attachment code needs a special way of
> handling attachment placement when it's invoked inside remember.
>
> A short-term fix might be to use advice to intercept calls to org- 
> attach
> when invoked inside a remember buffer and have it raise an error and
> tell you to wait until the remember note has been filed before  
> adding an
> attachment.
>
> [as an aside, this whole mess is caused because I have no way to  
> create
> an org link to an email from Thunderbird, so I have to handle all my
> email-related tasks through attachments.  Grrrr....]
>
> An alternative would be to have org-id-get handle remember buffers
> specially.  org-remember has some default location for putting its new
> item, and that could presumably be looked up.  However, given that one
> has the possibility of changing the destination of the note, this  
> would
> have to be handled carefully.  If (a) org-refile handles relocating
> attachments correctly and (b) the code in org-remember for handling,
> e.g., C-1 C-c C-c. uses the org-refile code; then this should be
> relatively easy to handle.
>
> Best,
> Robert
>

Re: Bug (?) adding attachment to note in remember buffer

[Carsten Dominik]

I forgot to say:  If you really want to create
attachments from remember buffers, you need to set
org-attach-directory to an absolute path, because
the default directory for a remember buffer may vary.

- Carsten

On Nov 18, 2008, at 8:59 AM, Carsten Dominik wrote:

> Fixed, thank for the report.
>
> - Carsten
>
> On Nov 17, 2008, at 5:20 PM, Robert Goldman wrote:
>
>> When I try to add an attachment to a note in the remember buffer, I  
>> get
>> an error that looks like this:
>>
>> Debugger entered--Lisp error: (wrong-type-argument arrayp nil)
>> file-truename(nil)
>> byte-code(xxxxx [org-id-locations list locs file id nil file-truename
>> throw exit t] 3)
>> org-id-add-location("xvsc3fr01ge0@sift.info" nil)
>> org-id-get(353 t)
>> org-attach-dir(t)
>> org-attach-attach("~/Desktop/hold-notification.eml" nil)
>> call-interactively(org-attach-attach)
>> org-attach()
>> call-interactively(org-attach)
>>
>> [sorry about the byte-code-garble]
>>
>> This is on the latest version, pulled from git this morning.
>>
>> Clearly what's wrong is the call to org-id-add-location with NIL as  
>> the
>> FILE argument.  That's the proximal cause.  The root cause seems to  
>> be
>> that when we call (buffer-file-name (buffer-base-buffer)) inside a
>> buffer created by org-remember, it returns nil (buffer-base-buffer  
>> is nil).
>>
>> This suggests that the org-attachment code needs a special way of
>> handling attachment placement when it's invoked inside remember.
>>
>> A short-term fix might be to use advice to intercept calls to org- 
>> attach
>> when invoked inside a remember buffer and have it raise an error and
>> tell you to wait until the remember note has been filed before  
>> adding an
>> attachment.
>>
>> [as an aside, this whole mess is caused because I have no way to  
>> create
>> an org link to an email from Thunderbird, so I have to handle all my
>> email-related tasks through attachments.  Grrrr....]
>>
>> An alternative would be to have org-id-get handle remember buffers
>> specially.  org-remember has some default location for putting its  
>> new
>> item, and that could presumably be looked up.  However, given that  
>> one
>> has the possibility of changing the destination of the note, this  
>> would
>> have to be handled carefully.  If (a) org-refile handles relocating
>> attachments correctly and (b) the code in org-remember for handling,
>> e.g., C-1 C-c C-c. uses the org-refile code; then this should be
>> relatively easy to handle.
>>
>> Best,
>> Robert
>>
>