bug related to ical

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@alum.mit.edu

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 <rjhorn@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
> rjhorn@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

[Tomi Ollila]

On Tue, Sep 25 2012, Olivier Berger <olivier.berger@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 <rjhorn@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
>> rjhorn@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

[Olivier Berger]

[-- Attachment #1: Type: text/plain, Size: 442 bytes --]

Hi.

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

Best regards,

Tomi Ollila <tomi.ollila@iki.fi> writes:

> On Tue, Sep 25 2012, Olivier Berger <olivier.berger@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
>



[-- Attachment #2: Type: message/rfc822, Size: 9007 bytes --]

[-- Attachment #2.1.1.1: Type: text/plain, Size: 93 bytes --]



Please find a calendar entry for the webcast attached.


(See attached file: iCalEvent.ics)

[-- Attachment #2.1.1.2: Type: text/html, Size: 148 bytes --]

[-- Attachment #2.1.2: iCalEvent.ics --]
[-- Type: application/octet-stream, Size: 1940 bytes --]

BEGIN:VCALENDAR
VERSION:2.0
METHOD:PUBLISH
BEGIN:VEVENT
UID:4e239439a9
DTSTAMP:20120924T133100Z
SUMMARY;CHARSET=UTF-8:OSLC Community Webcast: Eclipse Lyo Perl Modules for OSLC (A mini-cast 3-pack)
DESCRIPTION;CHARSET=UTF-8:Abstract:\n\nThis webcast will be presented in 3 parts:\n1. Details and demo of the Lyo-OSLC module [1] which is an OSLC CM client developed for use with Rational Team Concert and Rational ClearQuest. Presented by Max Vohlken.\n2. Details and demo of the Net-OSLC-CM module [2] which is a generic OSLC CM module that was developed for the Simple Defects [3] distributed bug tracking system. Presented by Stephanie Ouillon.\n3. A round table discussion of the differences between the two contributions, ongoing work, and areas for future work. Roundtable participants Olivier Berger, Mike Fiedler, Stephanie Ouillon, Max Vohlken, and Yuhong Yin\n\nEach part will be 7-9 minutes and will include time for questions.\n\n\nAbout the speakers:\n\n* Max Vohlken\n* Stephanie Ouillon\n* Olivier Berger [4] is a Research Engineer at the Institut Mines-Telecom, Telecom SudParis\n* Mike Fiedler is the co-lead of the Eclipse Lyo project.\n* Yuhong Yin\n\n  [1]: http://git.eclipse.org/c/lyo/org.eclipse.lyo.client.git/tree/org.eclipse.lyo.client.perl/Lyo-OSLC\n  [2]: http://git.eclipse.org/c/lyo/org.eclipse.lyo.client.git/tree/org.eclipse.lyo.client.perl/Net-OSLC-CM\n  [3]: http://syncwith.us/\n  [4]: http://www-public.it-sudparis.eu/~berger_o/\n\nBefore you join the event, test your system at:\nhttps://events.webdialogs.com/check.php?id=4e239439a9&role=2\n\nJoin the event at:\nhttps://events.webdialogs.com/join.php?id=4e239439a9&l=en-US\n\nJoin the Voice Conference \nTeleconference Access Number 1:1-888-426-6840\nTeleconference Access Number 2:more countries: http://bit.ly/OXn0Xd\nTeleconference ID:72560689#\n\n
DTSTART:20121016T150000Z
DTEND:20121016T160000Z
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR

[-- Attachment #3: Type: text/plain, Size: 182 bytes --]



-- 
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

[Tomi Ollila]

Hi

I am "top-posting" as the content is not from Olivier's mail
id:"87d31artti.fsf@inf-8657.int-evry.fr" but from my email
id:"m2ipb2tjl8.fsf@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.berger@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 <rjhorn@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
>>> rjhorn@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

[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

[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@inf-8657.int-evry.fr" but from my email
   id:"m2ipb2tjl8.fsf@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@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_

--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-icalXXXXXX 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

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_
>
> --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-icalXXXXXX 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

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.ollila@iki.fi>

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

Hope this helps.

Best regards,

Tomi Ollila <tomi.ollila@iki.fi> 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]

Olivier Berger <olivier.berger@it-sudparis.eu>
writes:

> Hi.
>
> Just in case, Tomi proposed an updated version in Message-ID:
> <1349333712-18347-1-git-send-email-tomi.ollila@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@iki.fi>
(http://permalink.gmane.org/gmane.mail.notmuch.general/12518) and
Message-ID: <1350826509-12119-1-git-send-email-tomi.ollila@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)