On Thu, Nov 22 2012, David Bremner <david@tethera.net> wrote: > Tomi Ollila <tomi.ollila@iki.fi> writes: > >> icalendar-import-buffer can fail by an error signal (which have been >> witnessed) but according to its docstring it can also return nil >> when failing (it returns t when succeeding). >> >> Now that the error is caught by the caller of notmuch-show-inset-part-* >> functions in case icalendar-import-buffer returns nil an explicit >> error is signaled and unwind-protect takes care of deleting the >> temporary file (just in case, it is usually not written to the fs yet). > > This one looks OK to me too, although the API that makes it necessary > out to be taken out back... I didn't quite understand the meaning of the last words... Anyway, the point in this patch is that if icalendar-import-buffer (or the older version using icalendar private functions) fail by returning nil, the error case is not (and has not been) shown to the user (user gets either empty or partially filled bodypart. Now that we would have that condition-case in the caller this code can signal error message to the user and provide info where more information can be obtained (*ical-errors* buffer). More complex code could be used to make notmuch-show-insert-part-text/calendar return nil in case icalendar-import-buffer fails -- then notmuch-show-insert-bodypart-internal would attempt to use next handler in chain to insert content (if any) > > d Tomi > _______________________________________________ > notmuch mailing list > notmuch@notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch