bug related to ical

[Olivier Berger]

Olivier Berger 
writes:

> Hi.
>
> Just in case, Tomi proposed an updated version in Message-ID:
> <1349333712-18347-1-git-send-email-tomi.ollila at iki.fi>
>
> ... but it doesn't seem to fix the issue for me :-/
>

Actually, this is not true, as I had forgotten to recompile the emacs
lisp before testing.

I do confirm that the patches in Message-ID:
<1349333712-18347-1-git-send-email-tomi.ollila at iki.fi>
(http://permalink.gmane.org/gmane.mail.notmuch.general/12518) and
Message-ID: <1350826509-12119-1-git-send-email-tomi.ollila at iki.fi>
(http://permalink.gmane.org/gmane.mail.notmuch.general/12631) seem to
solve the issue.

Hope this helps.

Best regards,
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

Re: bug related to ical

[Olivier Berger]

Olivier Berger olivier.ber...@it-sudparis.eu
writes:

 Hi.

 Just in case, Tomi proposed an updated version in Message-ID:
 1349333712-18347-1-git-send-email-tomi.oll...@iki.fi

 ... but it doesn't seem to fix the issue for me :-/


Actually, this is not true, as I had forgotten to recompile the emacs
lisp before testing.

I do confirm that the patches in Message-ID:
1349333712-18347-1-git-send-email-tomi.oll...@iki.fi
(http://permalink.gmane.org/gmane.mail.notmuch.general/12518) and
Message-ID: 1350826509-12119-1-git-send-email-tomi.oll...@iki.fi
(http://permalink.gmane.org/gmane.mail.notmuch.general/12631) seem to
solve the issue.

Hope this helps.

Best regards,
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

bug related to ical

[Olivier Berger]

Hi.

Just in case, Tomi proposed an updated version in Message-ID:
<1349333712-18347-1-git-send-email-tomi.ollila at iki.fi>

... but it doesn't seem to fix the issue for me :-/

Hope this helps.

Best regards,

Tomi Ollila  writes:

> On Wed, Oct 03 2012, Tomi Ollila wrote:
>
>> I've got the example in question to "work" with the following patch_
>>
>> --8<8<8<-- cut here  --8<8<8<--
>>
>> diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
>> index 86130ce..f7c08ee 100644
>> --- a/emacs/notmuch-show.el
>> +++ b/emacs/notmuch-show.el
>> @@ -747,17 +747,21 @@ message at DEPTH in the current thread."
>>(notmuch-show-insert-part-header nth declared-type content-type 
>> (plist-get part :filename))
>>(insert (with-temp-buffer
>>  (insert (notmuch-get-bodypart-content msg part nth 
>> notmuch-show-process-crypto))
>> -(goto-char (point-min))
>>  (let ((file (make-temp-file "notmuch-ical"))
>>result)
>> +  (set-buffer (icalendar--get-unfolded-buffer (current-buffer)))
>> +  (beginning-of-buffer)
>> +  (replace-string "" "")
>
> OK, something mangled my email, there used to be ^M above (as one char, CR
> .. maybe "\r" would have worked ?)
>
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

Re: bug related to ical

[Olivier Berger]

Hi.

Just in case, Tomi proposed an updated version in Message-ID:
1349333712-18347-1-git-send-email-tomi.oll...@iki.fi

... but it doesn't seem to fix the issue for me :-/

Hope this helps.

Best regards,

Tomi Ollila tomi.oll...@iki.fi writes:

 On Wed, Oct 03 2012, Tomi Ollila wrote:

 I've got the example in question to work with the following patch_

 --888-- cut here  --888--

 diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
 index 86130ce..f7c08ee 100644
 --- a/emacs/notmuch-show.el
 +++ b/emacs/notmuch-show.el
 @@ -747,17 +747,21 @@ message at DEPTH in the current thread.
(notmuch-show-insert-part-header nth declared-type content-type 
 (plist-get part :filename))
(insert (with-temp-buffer
  (insert (notmuch-get-bodypart-content msg part nth 
 notmuch-show-process-crypto))
 -(goto-char (point-min))
  (let ((file (make-temp-file notmuch-ical))
result)
 +  (set-buffer (icalendar--get-unfolded-buffer (current-buffer)))
 +  (beginning-of-buffer)
 +  (replace-string  )

 OK, something mangled my email, there used to be ^M above (as one char, CR
 .. maybe \r would have worked ?)

-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

bug related to ical

[Tomi Ollila]

On Wed, Oct 03 2012, Tomi Ollila wrote:

> On Wed, Sep 26 2012, Aaron Ecay wrote:
>
>> The problem is in the ?notmuch-show-insert-part-text/calendar?
>> function.  The call to ?icalendar--convert-ical-to-diary? does not
>> create a buffer visiting the temp file, so the call to ?set-buffer?
>> fails.  The following patch fixes the problem.
>>
>> The ical->diary conversion also doesn?t seem to work ? the calendar
>> attachment shows up as an empty part ? but I guess that?s a separate
>> issue (and not addressed by the patch).
>>
>> I guess that part insertion handlers should be called inside a
>> ?condition-case?, so that an error inside of one can be recovered from,
>> and doesn?t entirely derail the insertion of the messages in the buffer.
>> (I actually made this patch because I was so annoyed that Olivier?s
>> buggy test attachment made it impossible for me to read Tomi?s reply.)
>>
>> - cut here -
>>
>> diff --git i/emacs/notmuch-show.el w/emacs/notmuch-show.el
>> index ce5ea6f..4c89d7e 100644
>> --- i/emacs/notmuch-show.el
>> +++ w/emacs/notmuch-show.el
>> @@ -746,7 +746,7 @@ message at DEPTH in the current thread."
>>(icalendar--convert-ical-to-diary
>> (icalendar--read-element nil nil)
>> file t)
>> -  (set-buffer (get-file-buffer file))
>> +  (set-buffer (find-file-noselect file))
>>(setq result (buffer-substring (point-min) (point-max)))
>>(set-buffer-modified-p nil)
>>(kill-buffer (current-buffer))
>>
>> - cut here -
>
> The problem seems to be carriage returns in the attachment -- which goes
> unnotified when converting from octet-stream content.
>
> I've got the example in question to "work" with the following patch_
>
> --8<8<8<-- cut here  --8<8<8<--
>
> diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
> index 86130ce..f7c08ee 100644
> --- a/emacs/notmuch-show.el
> +++ b/emacs/notmuch-show.el
> @@ -747,17 +747,21 @@ message at DEPTH in the current thread."
>(notmuch-show-insert-part-header nth declared-type content-type (plist-get 
> part :filename))
>(insert (with-temp-buffer
>   (insert (notmuch-get-bodypart-content msg part nth 
> notmuch-show-process-crypto))
> - (goto-char (point-min))
>   (let ((file (make-temp-file "notmuch-ical"))
> result)
> +   (set-buffer (icalendar--get-unfolded-buffer (current-buffer)))
> +   (beginning-of-buffer)
> +   (replace-string "" "")

OK, something mangled my email, there used to be ^M above (as one char, CR
.. maybe "\r" would have worked ?)

Tomi


> +   (beginning-of-buffer)
> (icalendar--convert-ical-to-diary
>  (icalendar--read-element nil nil)
>  file t)
> +   (kill-buffer (current-buffer))
> (set-buffer (get-file-buffer file))
> (setq result (buffer-substring (point-min) (point-max)))
> (set-buffer-modified-p nil)
> (kill-buffer (current-buffer))
> -   (delete-file file)
> +   ;;;(delete-file file)
> result)))
>t)
>  
> --8<8<8<-- cut here  --8<8<8<--
>
> In our case the icalendar--get-unfolded-buffer doesn't seem
> to do any conversions (the docstring mentions some LF/CR/BLANK
> replacements) -- I just copied that line from icalendar-import-buffer
> which I tried first.
>
> The interesting thing is that the notmuch-icalXX file is
> still empty ... hmm, the buffer is just not saved (would /dev/null work ;))
>
> To do:
> Check why icalendar--get-unfolded-buffer did not do what it advertised;
> the code seems to support the replacements mentioned -- or maybe I failed ;/
>
> The problem with failing to icalendar--convert-ical-to-diary is that
> the buffer is not created. The find-file-noselect shields about that
> problem here but not elsewhere (and why that failure is so "fatal" ???)
> Some shielding in higher level should be implemented (i.e. the
> "condition-case" suggestion Aaron mentioned or something :)
>
>
> self to remember:  M-x debug-on-entry and keys 'd', 'u' and 'c' in debugger :)
>
> Tomi
>
>>
>> -- 
>> Aaron Ecay

bug related to ical

[Tomi Ollila]

On Wed, Sep 26 2012, Aaron Ecay wrote:

> The problem is in the ?notmuch-show-insert-part-text/calendar?
> function.  The call to ?icalendar--convert-ical-to-diary? does not
> create a buffer visiting the temp file, so the call to ?set-buffer?
> fails.  The following patch fixes the problem.
>
> The ical->diary conversion also doesn?t seem to work ? the calendar
> attachment shows up as an empty part ? but I guess that?s a separate
> issue (and not addressed by the patch).
>
> I guess that part insertion handlers should be called inside a
> ?condition-case?, so that an error inside of one can be recovered from,
> and doesn?t entirely derail the insertion of the messages in the buffer.
> (I actually made this patch because I was so annoyed that Olivier?s
> buggy test attachment made it impossible for me to read Tomi?s reply.)
>
> - cut here -
>
> diff --git i/emacs/notmuch-show.el w/emacs/notmuch-show.el
> index ce5ea6f..4c89d7e 100644
> --- i/emacs/notmuch-show.el
> +++ w/emacs/notmuch-show.el
> @@ -746,7 +746,7 @@ message at DEPTH in the current thread."
> (icalendar--convert-ical-to-diary
>  (icalendar--read-element nil nil)
>  file t)
> -   (set-buffer (get-file-buffer file))
> +   (set-buffer (find-file-noselect file))
> (setq result (buffer-substring (point-min) (point-max)))
> (set-buffer-modified-p nil)
> (kill-buffer (current-buffer))
>
> - cut here -

The problem seems to be carriage returns in the attachment -- which goes
unnotified when converting from octet-stream content.

I've got the example in question to "work" with the following patch_

--8<8<8<-- cut here  --8<8<8<--

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 86130ce..f7c08ee 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -747,17 +747,21 @@ message at DEPTH in the current thread."
   (notmuch-show-insert-part-header nth declared-type content-type (plist-get 
part :filename))
   (insert (with-temp-buffer
(insert (notmuch-get-bodypart-content msg part nth 
notmuch-show-process-crypto))
-   (goto-char (point-min))
(let ((file (make-temp-file "notmuch-ical"))
  result)
+ (set-buffer (icalendar--get-unfolded-buffer (current-buffer)))
+ (beginning-of-buffer)
+ (replace-string "" "")
+ (beginning-of-buffer)
  (icalendar--convert-ical-to-diary
   (icalendar--read-element nil nil)
   file t)
+ (kill-buffer (current-buffer))
  (set-buffer (get-file-buffer file))
  (setq result (buffer-substring (point-min) (point-max)))
  (set-buffer-modified-p nil)
  (kill-buffer (current-buffer))
- (delete-file file)
+ ;;;(delete-file file)
  result)))
   t)

--8<8<8<-- cut here  --8<8<8<--

In our case the icalendar--get-unfolded-buffer doesn't seem
to do any conversions (the docstring mentions some LF/CR/BLANK
replacements) -- I just copied that line from icalendar-import-buffer
which I tried first.

The interesting thing is that the notmuch-icalXX file is
still empty ... hmm, the buffer is just not saved (would /dev/null work ;))

To do:
Check why icalendar--get-unfolded-buffer did not do what it advertised;
the code seems to support the replacements mentioned -- or maybe I failed ;/

The problem with failing to icalendar--convert-ical-to-diary is that
the buffer is not created. The find-file-noselect shields about that
problem here but not elsewhere (and why that failure is so "fatal" ???)
Some shielding in higher level should be implemented (i.e. the
"condition-case" suggestion Aaron mentioned or something :)


self to remember:  M-x debug-on-entry and keys 'd', 'u' and 'c' in debugger :)

Tomi

>
> -- 
> Aaron Ecay
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

Re: bug related to ical

[Tomi Ollila]

On Wed, Sep 26 2012, Aaron Ecay wrote:

 The problem is in the ‘notmuch-show-insert-part-text/calendar’
 function.  The call to ‘icalendar--convert-ical-to-diary’ does not
 create a buffer visiting the temp file, so the call to ‘set-buffer’
 fails.  The following patch fixes the problem.

 The ical-diary conversion also doesn’t seem to work – the calendar
 attachment shows up as an empty part – but I guess that’s a separate
 issue (and not addressed by the patch).

 I guess that part insertion handlers should be called inside a
 ‘condition-case’, so that an error inside of one can be recovered from,
 and doesn’t entirely derail the insertion of the messages in the buffer.
 (I actually made this patch because I was so annoyed that Olivier’s
 buggy test attachment made it impossible for me to read Tomi’s reply.)

 - cut here -

 diff --git i/emacs/notmuch-show.el w/emacs/notmuch-show.el
 index ce5ea6f..4c89d7e 100644
 --- i/emacs/notmuch-show.el
 +++ w/emacs/notmuch-show.el
 @@ -746,7 +746,7 @@ message at DEPTH in the current thread.
 (icalendar--convert-ical-to-diary
  (icalendar--read-element nil nil)
  file t)
 -   (set-buffer (get-file-buffer file))
 +   (set-buffer (find-file-noselect file))
 (setq result (buffer-substring (point-min) (point-max)))
 (set-buffer-modified-p nil)
 (kill-buffer (current-buffer))

 - cut here -

The problem seems to be carriage returns in the attachment -- which goes
unnotified when converting from octet-stream content.

I've got the example in question to work with the following patch_

--888-- cut here  --888--

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 86130ce..f7c08ee 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -747,17 +747,21 @@ message at DEPTH in the current thread.
   (notmuch-show-insert-part-header nth declared-type content-type (plist-get 
part :filename))
   (insert (with-temp-buffer
(insert (notmuch-get-bodypart-content msg part nth 
notmuch-show-process-crypto))
-   (goto-char (point-min))
(let ((file (make-temp-file notmuch-ical))
  result)
+ (set-buffer (icalendar--get-unfolded-buffer (current-buffer)))
+ (beginning-of-buffer)
+ (replace-string  )
+ (beginning-of-buffer)
  (icalendar--convert-ical-to-diary
   (icalendar--read-element nil nil)
   file t)
+ (kill-buffer (current-buffer))
  (set-buffer (get-file-buffer file))
  (setq result (buffer-substring (point-min) (point-max)))
  (set-buffer-modified-p nil)
  (kill-buffer (current-buffer))
- (delete-file file)
+ ;;;(delete-file file)
  result)))
   t)
 
--888-- cut here  --888--

In our case the icalendar--get-unfolded-buffer doesn't seem
to do any conversions (the docstring mentions some LF/CR/BLANK
replacements) -- I just copied that line from icalendar-import-buffer
which I tried first.

The interesting thing is that the notmuch-icalXX file is
still empty ... hmm, the buffer is just not saved (would /dev/null work ;))

To do:
Check why icalendar--get-unfolded-buffer did not do what it advertised;
the code seems to support the replacements mentioned -- or maybe I failed ;/

The problem with failing to icalendar--convert-ical-to-diary is that
the buffer is not created. The find-file-noselect shields about that
problem here but not elsewhere (and why that failure is so fatal ???)
Some shielding in higher level should be implemented (i.e. the
condition-case suggestion Aaron mentioned or something :)


self to remember:  M-x debug-on-entry and keys 'd', 'u' and 'c' in debugger :)

Tomi


 -- 
 Aaron Ecay
 ___
 notmuch mailing list
 notmuch@notmuchmail.org
 http://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: bug related to ical

[Tomi Ollila]

On Wed, Oct 03 2012, Tomi Ollila wrote:

 On Wed, Sep 26 2012, Aaron Ecay wrote:

 The problem is in the ‘notmuch-show-insert-part-text/calendar’
 function.  The call to ‘icalendar--convert-ical-to-diary’ does not
 create a buffer visiting the temp file, so the call to ‘set-buffer’
 fails.  The following patch fixes the problem.

 The ical-diary conversion also doesn’t seem to work – the calendar
 attachment shows up as an empty part – but I guess that’s a separate
 issue (and not addressed by the patch).

 I guess that part insertion handlers should be called inside a
 ‘condition-case’, so that an error inside of one can be recovered from,
 and doesn’t entirely derail the insertion of the messages in the buffer.
 (I actually made this patch because I was so annoyed that Olivier’s
 buggy test attachment made it impossible for me to read Tomi’s reply.)

 - cut here -

 diff --git i/emacs/notmuch-show.el w/emacs/notmuch-show.el
 index ce5ea6f..4c89d7e 100644
 --- i/emacs/notmuch-show.el
 +++ w/emacs/notmuch-show.el
 @@ -746,7 +746,7 @@ message at DEPTH in the current thread.
(icalendar--convert-ical-to-diary
 (icalendar--read-element nil nil)
 file t)
 -  (set-buffer (get-file-buffer file))
 +  (set-buffer (find-file-noselect file))
(setq result (buffer-substring (point-min) (point-max)))
(set-buffer-modified-p nil)
(kill-buffer (current-buffer))

 - cut here -

 The problem seems to be carriage returns in the attachment -- which goes
 unnotified when converting from octet-stream content.

 I've got the example in question to work with the following patch_

 --888-- cut here  --888--

 diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
 index 86130ce..f7c08ee 100644
 --- a/emacs/notmuch-show.el
 +++ b/emacs/notmuch-show.el
 @@ -747,17 +747,21 @@ message at DEPTH in the current thread.
(notmuch-show-insert-part-header nth declared-type content-type (plist-get 
 part :filename))
(insert (with-temp-buffer
   (insert (notmuch-get-bodypart-content msg part nth 
 notmuch-show-process-crypto))
 - (goto-char (point-min))
   (let ((file (make-temp-file notmuch-ical))
 result)
 +   (set-buffer (icalendar--get-unfolded-buffer (current-buffer)))
 +   (beginning-of-buffer)
 +   (replace-string  )

OK, something mangled my email, there used to be ^M above (as one char, CR
.. maybe \r would have worked ?)

Tomi


 +   (beginning-of-buffer)
 (icalendar--convert-ical-to-diary
  (icalendar--read-element nil nil)
  file t)
 +   (kill-buffer (current-buffer))
 (set-buffer (get-file-buffer file))
 (setq result (buffer-substring (point-min) (point-max)))
 (set-buffer-modified-p nil)
 (kill-buffer (current-buffer))
 -   (delete-file file)
 +   ;;;(delete-file file)
 result)))
t)
  
 --888-- cut here  --888--

 In our case the icalendar--get-unfolded-buffer doesn't seem
 to do any conversions (the docstring mentions some LF/CR/BLANK
 replacements) -- I just copied that line from icalendar-import-buffer
 which I tried first.

 The interesting thing is that the notmuch-icalXX file is
 still empty ... hmm, the buffer is just not saved (would /dev/null work ;))

 To do:
 Check why icalendar--get-unfolded-buffer did not do what it advertised;
 the code seems to support the replacements mentioned -- or maybe I failed ;/

 The problem with failing to icalendar--convert-ical-to-diary is that
 the buffer is not created. The find-file-noselect shields about that
 problem here but not elsewhere (and why that failure is so fatal ???)
 Some shielding in higher level should be implemented (i.e. the
 condition-case suggestion Aaron mentioned or something :)


 self to remember:  M-x debug-on-entry and keys 'd', 'u' and 'c' in debugger :)

 Tomi


 -- 
 Aaron Ecay
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

bug related to ical

[Tomi Ollila]

On Wed, Sep 26 2012, Aaron Ecay wrote:

> The problem is in the ?notmuch-show-insert-part-text/calendar?
> function.  The call to ?icalendar--convert-ical-to-diary? does not
> create a buffer visiting the temp file, so the call to ?set-buffer?
> fails.  The following patch fixes the problem.
>
> The ical->diary conversion also doesn?t seem to work ? the calendar
> attachment shows up as an empty part ? but I guess that?s a separate
> issue (and not addressed by the patch).
>
> I guess that part insertion handlers should be called inside a
> ?condition-case?, so that an error inside of one can be recovered from,
> and doesn?t entirely derail the insertion of the messages in the buffer.
> (I actually made this patch because I was so annoyed that Olivier?s
> buggy test attachment made it impossible for me to read Tomi?s reply.)

My reply was:

--8<8<8<8<8<8<8<8<8<--
   Hi

   I am "top-posting" as the content is not from Olivier's mail
   id:"87d31artti.fsf at inf-8657.int-evry.fr" but from my email
   id:"m2ipb2tjl8.fsf at guru.guru-group.fi"...

   For some reason notmuch emacs client references to my email instead
   of Olivier's when pressing 'V', any of the stash commands, reply or
   so on. Maybe that has something to do accessing the ical content
   (i.e. emacs client access the ical part from wrong message).

   Do others experience the same behaviour ?

   Tomi
--8<8<8<8<8<8<8<8<8<--

When I hand-applied Aaron's patch and re-evaluated 
(defun notmuch-show-insert-part-text/calendar ...) and reopened
this thread those things I mentioned above started to work OK :)

Aaron: could you provide the patch in format suitable for git-am
so it could be easily applied (and hopefully quickly, provided
that we get reviewers to look at it immediately :)

Tomi

>
> - cut here -
>
> diff --git i/emacs/notmuch-show.el w/emacs/notmuch-show.el
> index ce5ea6f..4c89d7e 100644
> --- i/emacs/notmuch-show.el
> +++ w/emacs/notmuch-show.el
> @@ -746,7 +746,7 @@ message at DEPTH in the current thread."
> (icalendar--convert-ical-to-diary
>  (icalendar--read-element nil nil)
>  file t)
> -   (set-buffer (get-file-buffer file))
> +   (set-buffer (find-file-noselect file))
> (setq result (buffer-substring (point-min) (point-max)))
> (set-buffer-modified-p nil)
> (kill-buffer (current-buffer))
>
> - cut here -
>
> -- 
> Aaron Ecay
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

bug related to ical

[Tomi Ollila]

Hi

I am "top-posting" as the content is not from Olivier's mail
id:"87d31artti.fsf at inf-8657.int-evry.fr" but from my email
id:"m2ipb2tjl8.fsf at guru.guru-group.fi"...

For some reason notmuch emacs client references to my email instead
of Olivier's when pressing 'V', any of the stash commands, reply or
so on. Maybe that has something to do accessing the ical content
(i.e. emacs client access the ical part from wrong message).

Do others experience the same behaviour ?

Tomi



> On Tue, Sep 25 2012, Olivier Berger  wrote:
>
>> Hi.
>>
>> I didn't seem to find any followup.
>>
>> I'm experiencing a similar problem... Anyone with hints on how to solve
>> this ?
>
> Can either of you provide an email file that triggers this problem
> for others to test ?
>
> Tomi
>
>>
>> Thanks in advance.
>>
>> Best regards,
>>
>> Robert Horn  writes:
>>
>>> I've noticed a problem related to handling of ical attachments.  I'm
>>> using Notmuch 0.13 on Emacs 23.3.1.  I've done some basic
>>> troubleshooting.
>>>
>>> The problem arises with emails from Concur that include an ical
>>> attachment being viewed with the notmuch message viewer.  The problems
>>> are:
>>>  1. When opening the email there is sometimes the following mesage and
>>>  error in Emacs message buffer:
>>>   Converting icalendar...done
>>>   notmuch-show-insert-bodypart-internal: Wrong type argument: stringp, nil
>>>
>>>  2. Some (not all) of the view commands fail, e.g. "v", "V", "w".
>>>  Others work, like "m", and "q".
>>>
>>>  3. Examination of the /tmp directory shows notmuch-ical temp files being
>>>  created but they are zero length.
>>>
>>> This is related to the ical attachment.  When I editted one of the emails to
>>> remove the attachment, the problem went away.  I suspect it is related
>>> to the attachments being base64 encoded.  The header of the mime
>>> attachment shows:
>>>
>>> Content-Type: application/octet-stream;
>>> name="ConcurCalendarEntry.ics"
>>> Content-Transfer-Encoding: base64
>>> Content-Disposition: attachment;
>>> filename="ConcurCalendarEntry.ics"
>>>
>>> The encoding is correct.  The attachment decodes and looks right.  With
>>> some details obscured the attachment contains:
>>>
>>> BEGIN:VCALENDAR
>>> VERSION:2.0
>>> METHOD:PUBLISH
>>> BEGIN:VEVENT
>>> DTSTART:properly-formatted
>>> DTEND:properly-formatted
>>> DTSTAMP:properly-formatted
>>> LOCATION:
>>> SUMMARY:Concur Travel Itinerary
>>> DESCRIPTION:Lots of stuff
>>>  with about 80 lines of description. All indented properly.
>>> UID:properly-formatted
>>> PRIORITY:3
>>> TRANSP:TRANSPARENT
>>> END:VEVENT
>>> END:VCALENDAR
>>>
>>> I can live without the ics files, so fixing this is not a priority for
>>> me.  If there is someone interested in figuring this out, I've saved an
>>> email and can answer questions.  I got lost trying to follow the lisp
>>> code paths for attachments, so I'm not sure whether it's the text or the
>>> base64 that is being handed off to icalendar.
>>>
>>> R Horn
>>> rjhorn at alum.mit.edu
>>
>> -- 
>> Olivier BERGER 
>> http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
>> Ingenieur Recherche - Dept INF
>> Institut Mines-Telecom, Telecom SudParis, Evry (France)
>>
>> ___
>> notmuch mailing list
>> notmuch at notmuchmail.org
>> http://notmuchmail.org/mailman/listinfo/notmuch

bug related to ical

[Aaron Ecay]

The problem is in the ?notmuch-show-insert-part-text/calendar?
function.  The call to ?icalendar--convert-ical-to-diary? does not
create a buffer visiting the temp file, so the call to ?set-buffer?
fails.  The following patch fixes the problem.

The ical->diary conversion also doesn?t seem to work ? the calendar
attachment shows up as an empty part ? but I guess that?s a separate
issue (and not addressed by the patch).

I guess that part insertion handlers should be called inside a
?condition-case?, so that an error inside of one can be recovered from,
and doesn?t entirely derail the insertion of the messages in the buffer.
(I actually made this patch because I was so annoyed that Olivier?s
buggy test attachment made it impossible for me to read Tomi?s reply.)

- cut here -

diff --git i/emacs/notmuch-show.el w/emacs/notmuch-show.el
index ce5ea6f..4c89d7e 100644
--- i/emacs/notmuch-show.el
+++ w/emacs/notmuch-show.el
@@ -746,7 +746,7 @@ message at DEPTH in the current thread."
  (icalendar--convert-ical-to-diary
   (icalendar--read-element nil nil)
   file t)
- (set-buffer (get-file-buffer file))
+ (set-buffer (find-file-noselect file))
  (setq result (buffer-substring (point-min) (point-max)))
  (set-buffer-modified-p nil)
  (kill-buffer (current-buffer))

- cut here -

-- 
Aaron Ecay

Re: bug related to ical

[Aaron Ecay]

The problem is in the ‘notmuch-show-insert-part-text/calendar’
function.  The call to ‘icalendar--convert-ical-to-diary’ does not
create a buffer visiting the temp file, so the call to ‘set-buffer’
fails.  The following patch fixes the problem.

The ical-diary conversion also doesn’t seem to work – the calendar
attachment shows up as an empty part – but I guess that’s a separate
issue (and not addressed by the patch).

I guess that part insertion handlers should be called inside a
‘condition-case’, so that an error inside of one can be recovered from,
and doesn’t entirely derail the insertion of the messages in the buffer.
(I actually made this patch because I was so annoyed that Olivier’s
buggy test attachment made it impossible for me to read Tomi’s reply.)

- cut here -

diff --git i/emacs/notmuch-show.el w/emacs/notmuch-show.el
index ce5ea6f..4c89d7e 100644
--- i/emacs/notmuch-show.el
+++ w/emacs/notmuch-show.el
@@ -746,7 +746,7 @@ message at DEPTH in the current thread.
  (icalendar--convert-ical-to-diary
   (icalendar--read-element nil nil)
   file t)
- (set-buffer (get-file-buffer file))
+ (set-buffer (find-file-noselect file))
  (setq result (buffer-substring (point-min) (point-max)))
  (set-buffer-modified-p nil)
  (kill-buffer (current-buffer))

- cut here -

-- 
Aaron Ecay
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: bug related to ical

[Tomi Ollila]

On Wed, Sep 26 2012, Aaron Ecay wrote:

 The problem is in the ‘notmuch-show-insert-part-text/calendar’
 function.  The call to ‘icalendar--convert-ical-to-diary’ does not
 create a buffer visiting the temp file, so the call to ‘set-buffer’
 fails.  The following patch fixes the problem.

 The ical-diary conversion also doesn’t seem to work – the calendar
 attachment shows up as an empty part – but I guess that’s a separate
 issue (and not addressed by the patch).

 I guess that part insertion handlers should be called inside a
 ‘condition-case’, so that an error inside of one can be recovered from,
 and doesn’t entirely derail the insertion of the messages in the buffer.
 (I actually made this patch because I was so annoyed that Olivier’s
 buggy test attachment made it impossible for me to read Tomi’s reply.)

My reply was:

--888888888--
   Hi

   I am top-posting as the content is not from Olivier's mail
   id:87d31artti@inf-8657.int-evry.fr but from my email
   id:m2ipb2tjl8@guru.guru-group.fi...

   For some reason notmuch emacs client references to my email instead
   of Olivier's when pressing 'V', any of the stash commands, reply or
   so on. Maybe that has something to do accessing the ical content
   (i.e. emacs client access the ical part from wrong message).

   Do others experience the same behaviour ?

   Tomi
--888888888--

When I hand-applied Aaron's patch and re-evaluated 
(defun notmuch-show-insert-part-text/calendar ...) and reopened
this thread those things I mentioned above started to work OK :)

Aaron: could you provide the patch in format suitable for git-am
so it could be easily applied (and hopefully quickly, provided
that we get reviewers to look at it immediately :)

Tomi


 - cut here -

 diff --git i/emacs/notmuch-show.el w/emacs/notmuch-show.el
 index ce5ea6f..4c89d7e 100644
 --- i/emacs/notmuch-show.el
 +++ w/emacs/notmuch-show.el
 @@ -746,7 +746,7 @@ message at DEPTH in the current thread.
 (icalendar--convert-ical-to-diary
  (icalendar--read-element nil nil)
  file t)
 -   (set-buffer (get-file-buffer file))
 +   (set-buffer (find-file-noselect file))
 (setq result (buffer-substring (point-min) (point-max)))
 (set-buffer-modified-p nil)
 (kill-buffer (current-buffer))

 - cut here -

 -- 
 Aaron Ecay
 ___
 notmuch mailing list
 notmuch@notmuchmail.org
 http://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

bug related to ical

[Olivier Berger]

Hi.

Here's a mail which exhibits the problem, for instance.

Best regards,

Tomi Ollila  writes:

> On Tue, Sep 25 2012, Olivier Berger  wrote:
>
>> Hi.
>>
>> I didn't seem to find any followup.
>>
>> I'm experiencing a similar problem... Anyone with hints on how to solve
>> this ?
>
> Can either of you provide an email file that triggers this problem
> for others to test ?
>
> Tomi
>


-- next part --
An embedded message was scrubbed...
From: olivier.ber...@it-sudparis.eu
Subject: Fw: Forward this e-mail to the presenters of the Event "OSLC Community 
Webcast: Eclipse Lyo Perl Modules for OSLC (A mini-cast 3-pack)"
Date: Mon, 24 Sep 2012 09:33:37 -0400
Size: 9056
URL: 

-- next part --


-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

bug related to ical

[Tomi Ollila]

On Tue, Sep 25 2012, Olivier Berger  wrote:

> Hi.
>
> I didn't seem to find any followup.
>
> I'm experiencing a similar problem... Anyone with hints on how to solve
> this ?

Can either of you provide an email file that triggers this problem
for others to test ?

Tomi

>
> Thanks in advance.
>
> Best regards,
>
> Robert Horn  writes:
>
>> I've noticed a problem related to handling of ical attachments.  I'm
>> using Notmuch 0.13 on Emacs 23.3.1.  I've done some basic
>> troubleshooting.
>>
>> The problem arises with emails from Concur that include an ical
>> attachment being viewed with the notmuch message viewer.  The problems
>> are:
>>  1. When opening the email there is sometimes the following mesage and
>>  error in Emacs message buffer:
>>   Converting icalendar...done
>>   notmuch-show-insert-bodypart-internal: Wrong type argument: stringp, nil
>>
>>  2. Some (not all) of the view commands fail, e.g. "v", "V", "w".
>>  Others work, like "m", and "q".
>>
>>  3. Examination of the /tmp directory shows notmuch-ical temp files being
>>  created but they are zero length.
>>
>> This is related to the ical attachment.  When I editted one of the emails to
>> remove the attachment, the problem went away.  I suspect it is related
>> to the attachments being base64 encoded.  The header of the mime
>> attachment shows:
>>
>> Content-Type: application/octet-stream;
>>  name="ConcurCalendarEntry.ics"
>> Content-Transfer-Encoding: base64
>> Content-Disposition: attachment;
>>  filename="ConcurCalendarEntry.ics"
>>
>> The encoding is correct.  The attachment decodes and looks right.  With
>> some details obscured the attachment contains:
>>
>> BEGIN:VCALENDAR
>> VERSION:2.0
>> METHOD:PUBLISH
>> BEGIN:VEVENT
>> DTSTART:properly-formatted
>> DTEND:properly-formatted
>> DTSTAMP:properly-formatted
>> LOCATION:
>> SUMMARY:Concur Travel Itinerary
>> DESCRIPTION:Lots of stuff
>>  with about 80 lines of description. All indented properly.
>> UID:properly-formatted
>> PRIORITY:3
>> TRANSP:TRANSPARENT
>> END:VEVENT
>> END:VCALENDAR
>>
>> I can live without the ics files, so fixing this is not a priority for
>> me.  If there is someone interested in figuring this out, I've saved an
>> email and can answer questions.  I got lost trying to follow the lisp
>> code paths for attachments, so I'm not sure whether it's the text or the
>> base64 that is being handed off to icalendar.
>>
>> R Horn
>> rjhorn at alum.mit.edu
>
> -- 
> Olivier BERGER 
> http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
> Ingenieur Recherche - Dept INF
> Institut Mines-Telecom, Telecom SudParis, Evry (France)
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

bug related to ical

[Olivier Berger]

Hi.

I didn't seem to find any followup.

I'm experiencing a similar problem... Anyone with hints on how to solve
this ?

Thanks in advance.

Best regards,

Robert Horn  writes:

> I've noticed a problem related to handling of ical attachments.  I'm
> using Notmuch 0.13 on Emacs 23.3.1.  I've done some basic
> troubleshooting.
>
> The problem arises with emails from Concur that include an ical
> attachment being viewed with the notmuch message viewer.  The problems
> are:
>  1. When opening the email there is sometimes the following mesage and
>  error in Emacs message buffer:
>   Converting icalendar...done
>   notmuch-show-insert-bodypart-internal: Wrong type argument: stringp, nil
>
>  2. Some (not all) of the view commands fail, e.g. "v", "V", "w".
>  Others work, like "m", and "q".
>
>  3. Examination of the /tmp directory shows notmuch-ical temp files being
>  created but they are zero length.
>
> This is related to the ical attachment.  When I editted one of the emails to
> remove the attachment, the problem went away.  I suspect it is related
> to the attachments being base64 encoded.  The header of the mime
> attachment shows:
>
> Content-Type: application/octet-stream;
>   name="ConcurCalendarEntry.ics"
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment;
>   filename="ConcurCalendarEntry.ics"
>
> The encoding is correct.  The attachment decodes and looks right.  With
> some details obscured the attachment contains:
>
> BEGIN:VCALENDAR
> VERSION:2.0
> METHOD:PUBLISH
> BEGIN:VEVENT
> DTSTART:properly-formatted
> DTEND:properly-formatted
> DTSTAMP:properly-formatted
> LOCATION:
> SUMMARY:Concur Travel Itinerary
> DESCRIPTION:Lots of stuff
>  with about 80 lines of description. All indented properly.
> UID:properly-formatted
> PRIORITY:3
> TRANSP:TRANSPARENT
> END:VEVENT
> END:VCALENDAR
>
> I can live without the ics files, so fixing this is not a priority for
> me.  If there is someone interested in figuring this out, I've saved an
> email and can answer questions.  I got lost trying to follow the lisp
> code paths for attachments, so I'm not sure whether it's the text or the
> base64 that is being handed off to icalendar.
>
> R Horn
> rjhorn at alum.mit.edu

-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

Re: bug related to ical

[Olivier Berger]

Hi.

I didn't seem to find any followup.

I'm experiencing a similar problem... Anyone with hints on how to solve
this ?

Thanks in advance.

Best regards,

Robert Horn rjh...@alum.mit.edu writes:

 I've noticed a problem related to handling of ical attachments.  I'm
 using Notmuch 0.13 on Emacs 23.3.1.  I've done some basic
 troubleshooting.

 The problem arises with emails from Concur that include an ical
 attachment being viewed with the notmuch message viewer.  The problems
 are:
  1. When opening the email there is sometimes the following mesage and
  error in Emacs message buffer:
   Converting icalendar...done
   notmuch-show-insert-bodypart-internal: Wrong type argument: stringp, nil

  2. Some (not all) of the view commands fail, e.g. v, V, w.
  Others work, like m, and q.

  3. Examination of the /tmp directory shows notmuch-ical temp files being
  created but they are zero length.

 This is related to the ical attachment.  When I editted one of the emails to
 remove the attachment, the problem went away.  I suspect it is related
 to the attachments being base64 encoded.  The header of the mime
 attachment shows:

 Content-Type: application/octet-stream;
   name=ConcurCalendarEntry.ics
 Content-Transfer-Encoding: base64
 Content-Disposition: attachment;
   filename=ConcurCalendarEntry.ics

 The encoding is correct.  The attachment decodes and looks right.  With
 some details obscured the attachment contains:

 BEGIN:VCALENDAR
 VERSION:2.0
 METHOD:PUBLISH
 BEGIN:VEVENT
 DTSTART:properly-formatted
 DTEND:properly-formatted
 DTSTAMP:properly-formatted
 LOCATION:
 SUMMARY:Concur Travel Itinerary
 DESCRIPTION:Lots of stuff
  with about 80 lines of description. All indented properly.
 UID:properly-formatted
 PRIORITY:3
 TRANSP:TRANSPARENT
 END:VEVENT
 END:VCALENDAR

 I can live without the ics files, so fixing this is not a priority for
 me.  If there is someone interested in figuring this out, I've saved an
 email and can answer questions.  I got lost trying to follow the lisp
 code paths for attachments, so I'm not sure whether it's the text or the
 base64 that is being handed off to icalendar.

 R Horn
 rjh...@alum.mit.edu

-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: bug related to ical

[Tomi Ollila]

On Tue, Sep 25 2012, Olivier Berger olivier.ber...@it-sudparis.eu wrote:

 Hi.

 I didn't seem to find any followup.

 I'm experiencing a similar problem... Anyone with hints on how to solve
 this ?

Can either of you provide an email file that triggers this problem
for others to test ?

Tomi


 Thanks in advance.

 Best regards,

 Robert Horn rjh...@alum.mit.edu writes:

 I've noticed a problem related to handling of ical attachments.  I'm
 using Notmuch 0.13 on Emacs 23.3.1.  I've done some basic
 troubleshooting.

 The problem arises with emails from Concur that include an ical
 attachment being viewed with the notmuch message viewer.  The problems
 are:
  1. When opening the email there is sometimes the following mesage and
  error in Emacs message buffer:
   Converting icalendar...done
   notmuch-show-insert-bodypart-internal: Wrong type argument: stringp, nil

  2. Some (not all) of the view commands fail, e.g. v, V, w.
  Others work, like m, and q.

  3. Examination of the /tmp directory shows notmuch-ical temp files being
  created but they are zero length.

 This is related to the ical attachment.  When I editted one of the emails to
 remove the attachment, the problem went away.  I suspect it is related
 to the attachments being base64 encoded.  The header of the mime
 attachment shows:

 Content-Type: application/octet-stream;
  name=ConcurCalendarEntry.ics
 Content-Transfer-Encoding: base64
 Content-Disposition: attachment;
  filename=ConcurCalendarEntry.ics

 The encoding is correct.  The attachment decodes and looks right.  With
 some details obscured the attachment contains:

 BEGIN:VCALENDAR
 VERSION:2.0
 METHOD:PUBLISH
 BEGIN:VEVENT
 DTSTART:properly-formatted
 DTEND:properly-formatted
 DTSTAMP:properly-formatted
 LOCATION:
 SUMMARY:Concur Travel Itinerary
 DESCRIPTION:Lots of stuff
  with about 80 lines of description. All indented properly.
 UID:properly-formatted
 PRIORITY:3
 TRANSP:TRANSPARENT
 END:VEVENT
 END:VCALENDAR

 I can live without the ics files, so fixing this is not a priority for
 me.  If there is someone interested in figuring this out, I've saved an
 email and can answer questions.  I got lost trying to follow the lisp
 code paths for attachments, so I'm not sure whether it's the text or the
 base64 that is being handed off to icalendar.

 R Horn
 rjh...@alum.mit.edu

 -- 
 Olivier BERGER 
 http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
 Ingenieur Recherche - Dept INF
 Institut Mines-Telecom, Telecom SudParis, Evry (France)

 ___
 notmuch mailing list
 notmuch@notmuchmail.org
 http://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: bug related to ical

[Olivier Berger]

Hi.

Here's a mail which exhibits the problem, for instance.

Best regards,

Tomi Ollila tomi.oll...@iki.fi writes:

 On Tue, Sep 25 2012, Olivier Berger olivier.ber...@it-sudparis.eu wrote:

 Hi.

 I didn't seem to find any followup.

 I'm experiencing a similar problem... Anyone with hints on how to solve
 this ?

 Can either of you provide an email file that triggers this problem
 for others to test ?

 Tomi



---BeginMessage---


Please find a calendar entry for the webcast attached.


(See attached file: iCalEvent.ics)

iCalEvent.ics
Description: Binary data
---End Message---


-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: bug related to ical

[Tomi Ollila]

Hi

I am top-posting as the content is not from Olivier's mail
id:87d31artti@inf-8657.int-evry.fr but from my email
id:m2ipb2tjl8@guru.guru-group.fi...

For some reason notmuch emacs client references to my email instead
of Olivier's when pressing 'V', any of the stash commands, reply or
so on. Maybe that has something to do accessing the ical content
(i.e. emacs client access the ical part from wrong message).

Do others experience the same behaviour ?

Tomi



 On Tue, Sep 25 2012, Olivier Berger olivier.ber...@it-sudparis.eu wrote:

 Hi.

 I didn't seem to find any followup.

 I'm experiencing a similar problem... Anyone with hints on how to solve
 this ?

 Can either of you provide an email file that triggers this problem
 for others to test ?

 Tomi


 Thanks in advance.

 Best regards,

 Robert Horn rjh...@alum.mit.edu writes:

 I've noticed a problem related to handling of ical attachments.  I'm
 using Notmuch 0.13 on Emacs 23.3.1.  I've done some basic
 troubleshooting.

 The problem arises with emails from Concur that include an ical
 attachment being viewed with the notmuch message viewer.  The problems
 are:
  1. When opening the email there is sometimes the following mesage and
  error in Emacs message buffer:
   Converting icalendar...done
   notmuch-show-insert-bodypart-internal: Wrong type argument: stringp, nil

  2. Some (not all) of the view commands fail, e.g. v, V, w.
  Others work, like m, and q.

  3. Examination of the /tmp directory shows notmuch-ical temp files being
  created but they are zero length.

 This is related to the ical attachment.  When I editted one of the emails to
 remove the attachment, the problem went away.  I suspect it is related
 to the attachments being base64 encoded.  The header of the mime
 attachment shows:

 Content-Type: application/octet-stream;
 name=ConcurCalendarEntry.ics
 Content-Transfer-Encoding: base64
 Content-Disposition: attachment;
 filename=ConcurCalendarEntry.ics

 The encoding is correct.  The attachment decodes and looks right.  With
 some details obscured the attachment contains:

 BEGIN:VCALENDAR
 VERSION:2.0
 METHOD:PUBLISH
 BEGIN:VEVENT
 DTSTART:properly-formatted
 DTEND:properly-formatted
 DTSTAMP:properly-formatted
 LOCATION:
 SUMMARY:Concur Travel Itinerary
 DESCRIPTION:Lots of stuff
  with about 80 lines of description. All indented properly.
 UID:properly-formatted
 PRIORITY:3
 TRANSP:TRANSPARENT
 END:VEVENT
 END:VCALENDAR

 I can live without the ics files, so fixing this is not a priority for
 me.  If there is someone interested in figuring this out, I've saved an
 email and can answer questions.  I got lost trying to follow the lisp
 code paths for attachments, so I'm not sure whether it's the text or the
 base64 that is being handed off to icalendar.

 R Horn
 rjh...@alum.mit.edu

 -- 
 Olivier BERGER 
 http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
 Ingenieur Recherche - Dept INF
 Institut Mines-Telecom, Telecom SudParis, Evry (France)

 ___
 notmuch mailing list
 notmuch@notmuchmail.org
 http://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

bug related to ical

[Robert Horn]

I've noticed a problem related to handling of ical attachments.  I'm
using Notmuch 0.13 on Emacs 23.3.1.  I've done some basic
troubleshooting.

The problem arises with emails from Concur that include an ical
attachment being viewed with the notmuch message viewer.  The problems
are:
 1. When opening the email there is sometimes the following mesage and
 error in Emacs message buffer:
  Converting icalendar...done
  notmuch-show-insert-bodypart-internal: Wrong type argument: stringp, nil

 2. Some (not all) of the view commands fail, e.g. "v", "V", "w".
 Others work, like "m", and "q".

 3. Examination of the /tmp directory shows notmuch-ical temp files being
 created but they are zero length.

This is related to the ical attachment.  When I editted one of the emails to
remove the attachment, the problem went away.  I suspect it is related
to the attachments being base64 encoded.  The header of the mime
attachment shows:

Content-Type: application/octet-stream;
name="ConcurCalendarEntry.ics"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="ConcurCalendarEntry.ics"

The encoding is correct.  The attachment decodes and looks right.  With
some details obscured the attachment contains:

BEGIN:VCALENDAR
VERSION:2.0
METHOD:PUBLISH
BEGIN:VEVENT
DTSTART:properly-formatted
DTEND:properly-formatted
DTSTAMP:properly-formatted
LOCATION:
SUMMARY:Concur Travel Itinerary
DESCRIPTION:Lots of stuff
 with about 80 lines of description. All indented properly.
UID:properly-formatted
PRIORITY:3
TRANSP:TRANSPARENT
END:VEVENT
END:VCALENDAR

I can live without the ics files, so fixing this is not a priority for
me.  If there is someone interested in figuring this out, I've saved an
email and can answer questions.  I got lost trying to follow the lisp
code paths for attachments, so I'm not sure whether it's the text or the
base64 that is being handed off to icalendar.

R Horn
rjhorn at alum.mit.edu