notmuch-emacs won't display correctly quoted-printable iso-8859-1 mails

[Olivier Berger]

Hi.

(message previously sent privately, and resent to the list and BTS for reference)

On Sun, 18 Dec 2011 18:08:55 +0200, Tomi Ollila <tomi.ollila at iki.fi> wrote:
> On Sun, 18 Dec 2011 15:53:26 +0100, Olivier Berger <olivier.berger at it-sudparis.eu> wrote:
> > On Sun, 18 Dec 2011 10:11:37 -0400, David Bremner <david at tethera.net> wrote:
> > > Hi Olivier;
> > > 
> > > Can you try the following patch? If you apply it to git, you can use
> > > "make debian-snapshot" to build new packages (assuming you have the
> > > pre-reqs).
> > > 
> > > Or just patch the notmuch-query.el installed by notmuch-emacs and reload
> > > it.
> > > 
> > 
> > I did that over notmuch-emacs 0.10.2-1 Debian package's version of
> > notmuch-query.el, but that doesn't seem change anything, unfortunately :
> > the modeline still is '-1:%*-' for the notmuch-show buffer, after
> > hitting RET over a message's line in a search result list :-(
> 
> I tested the same on terminal configured for latin9 and LC_ALL=fi_FI at euro
> and the change worked for me.

Glad for you... but did it work before too, by any chance ?

Maybe it wasn't clear in my report, bug I'm using emacs23 in X, and not
in terminal. Which is different from your tests, AFAIU.

> 
> The buffer modeline is not supposed to change -- the change makes emacs
> read incoming data encoded in utf-8 format (notmuch outputs everything
> in utf-8). Before the change emacs expected (in your case) input data being
> in latin1 format ("guessed" from your locale), but as input was in utf-8 the
> conversion to emacs internal format went wrong.

My locale is : fr_FR.utf8 ... maybe you're guessing a bit too much, and
again, emacs runs in X... as for your modeline explanation, it's not
really clear I'm afraid. I have always had the impression that the
modeline should be starting with -U:... if I'm supposed to display
correctly some UTF-8 characters, which is not the case, hence the
problem. I don't know what else should happen. So AFAICT, the goal is to
make sure the buffer is indeed "opened" as UTF-8, or rendered as UTF-8,
although I couldn't tell how emacs does this all, to be able to
understand the patch correctly.

> 
> When emacs displays something (buffer content, that is) it converts the
> internal format to the encoding emacs window is using. 
> 
> So, my guess is you did something wrong when trying David's patch and
> you did not get the change evaluated.
> 

I don't think so.

> This what I did:
> 
> I opened emacs/notmuch-query.el to another emacs window while 
> notmuch-hello open in another window.
> 
> Then I added line (coding-system-for-read 'utf-8) in line 35:
> 
>   (let  ((args '("show" "--format=json"))
>          (json-object-type 'plist)
>          (json-array-type 'list)
>          (coding-system-for-read 'utf-8)
>          (json-false 'nil))
> 

Uh, is this really the patch suggested by David ?

Ain't it supposed to be :
  --- a/emacs/notmuch-query.el
  +++ b/emacs/notmuch-query.el
  @@ -38,7 +38,7 @@ is a possibly empty forest of replies.
       (setq args (append args search-terms))
       (with-temp-buffer
	 (progn
  -	(apply 'call-process (append (list notmuch-command nil (list t nil) nil) args))
  +	(let ((coding-system-for-read 'utf-8)) (apply 'call-process (append (list notmuch-command nil (list t nil) nil) args)))
	  (goto-char (point-min))
	  (json-read)))))

Anyway, I had quit emacs, then patched the file with the above patch,
and restarted it, so I don't know what could have gone wrong.

> then moved cursor to the end of line 44 which shows: (json-read)))))
> (last line of that function) and entered c-x c-e
> (eval-last-sexp) -- that re-evaluates the function definition.
> 
> And, as said, after that change my emails render correctly on
> latin1 -terminal (as opposed those did not render correctly before)
> 

OK, so maybe that's one fix for the terminal, but not yet complete for
the X/Gtk Emacs windows.

> > Hope this helps.
> 
> I hope that I'm right in my guess so we get forward easier... :)
> 

A bit too much guessing I'm afraid ;)

Thanks anyway for your help.

Best regards,

-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)