[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Duplicate In-Reply-To entries in reply buffer



At Mon, 16 Jul 2012 10:16:45 +0900,
Kazuhiro Ito wrote:
> >
> > I pushed a modified version of this patch to master @
> > wanderlust/wanderlust that also implements a modified version of the
> > fix for unfolding message-id suggested in
> > <mid:rfwmx62teq6.wl%Don.Bashford@stjude.org>.

> I think we can't simply use elmo-msgdb-get-message-id-from-buffer
> instead of (std11-field-body "message-id").  Because,

> 1. elmo-msgdb-get-message-id-from-buffer uses elmo-unfold-field-body
> (or elmo-unfold-field-body, previously), which assumes buffer is
> narrrowed to the message header.

Technically this is correct and so does `elmo-field-body' in current
`elmo-msgdb-get-message-id-from-buffer'. But when msgdb-get-message-id
is called in `elmo-folder-append-buffer' the buffer is not narrowed to
the headers neither.

If you switch to the temporary buffer you will see that it is not
narrowed to the header. If you modify the buffer and add a line
`Message-Id: <foo@bar.baz>' in the message body then WL will pick up
<foo@bar.baz> as message-id.

A part I quite don't understand is the defalias in elmo-util.el:

,----
| (eval-and-compile
|   (if (fboundp 'std11-fetch-field)
|       (defalias 'elmo-field-body 'std11-fetch-field) ;;no narrow-to-region
|     (defalias 'elmo-field-body 'std11-field-body)))
`----

This code was already present with the first commit to WL repository
back in 2000 and the only reason I could think of why one would use
this defalias is to avoid (unnecessary) calls to narrow-to-region.

If I see this right we are talking about two scenarios:

 (1) Obtain the message-id in order to store it in the message database

 (2) Obtain the message-id in order to create the
     in-reply-to/references header fields

Obtaining a message-id is common to both scenarios, the difference is
in the handling of a missing or invalid message-id. I refactored
accordingly (see attached path or [1]) still using a very sloppy
regexp to detect malformed message-id header.

> I think it would be better not using elmo-unfold-field-body for the
> sake of speed.

If using `elmo-unfold-field-body' has a noticable and measurable
impact on the overall performance then we need to think about a better
way to unfold and maybe use an algorithm that is `good enough'.

Best,
  -- David

[1] https://github.com/dmj/wanderlust/commit/19a649a8f4dcf085255a560ca9b99abb860f5a15
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber.... dmjena@jabber.org
Email..... dmaus@ictsoc.de

Attachment: pgpYh7v2gnVP6.pgp
Description: OpenPGP Digital Signature