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 <olivier.berger at 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 at 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 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