Re: [PATCH 1/1] NEWS: under-the-hood Emacs interface fixes

Subject: Re: [PATCH 1/1] NEWS: under-the-hood Emacs interface fixes

Date: Fri, 7 Dec 2012 11:33:20 -0500

To: Tomi Ollila

Cc: notmuch@notmuchmail.org

From: Austin Clements


Quoth Tomi Ollila on Dec 03 at 12:48 am:
> Added the following Emacs Interface NEWS entries:
> 
> Catch errors bodypart insertions may throw,
> Improved text/calendar content handling and
> Don't do coding conversions when reading in
> `with-current-notmuch-show-message`.
> ---
>  NEWS | 25 +++++++++++++++++++++++++
>  1 file changed, 25 insertions(+)
> 
> diff --git a/NEWS b/NEWS
> index dadf92a..1d0c840 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -18,6 +18,31 @@ Bcc and Reply-To headers are now available in notmuch show json output
>    For example notmuch Emacs client can now have these headers visible
>    when the headers are added to the `notmuch-message-headers` variable.
>  
> +Emacs Interface
> +---------------
> +
> +Catch errors bodypart insertions may throw
> +
> +Whenever anything inside `notmuch-show-insert-part-*` functions
> +threw an error then filling of notmuch show buffer halted there.
> +Now the error is caught, user is informed about the error
> +and execution is continued with next content filling function.

Should these blocks be indented?

Also, this could be a little more user-facing.  Maybe,

  If displaying the text of a message in show mode causes an error (in
  the `notmuch-show-insert-part-*` functions), notmuch no longer cuts
  off thread display at the offending message.  The error is now
  simply displayed in place of the message.

> +
> +Improved text/calendar content handling
> +
> +Carriage returns in embedded text/calendar content caused insertion
> +of calendar content fail. Now CRs are removed before calling icalendar
> +to extract icalendar data. In case icalendar extraction fails an error
> +is thrown for bodypart insertion function to react upon it.
> +
> +Don't do coding conversions when reading in `with-current-notmuch-show-message`
> +
> +In locales that support more than 8-bit characters reading data in
> +`with-current-notmuch-show-message` converted data to multibyte format.
> +Some cases reversing the conversion did not provide original data. Now
> +the input octet stream is buffered in non-converted format for further
> +processing.

This doesn't mention the ultimate effect of this bug.

  Depending on the user's locale, saving attachments containing 8-bit
  data may have performed an unintentional encoding conversion,
  corrupting the saved attachment.  This has been fixed by making
  `with-current-notmuch-show-message` disable coding conversion.

?

> +
>  Library changes
>  ---------------
>  

Thread: