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@iki.fi> wrote: > On Sun, 18 Dec 2011 15:53:26 +0100, Olivier Berger <olivier.berger@it-sudparis.eu> wrote: > > On Sun, 18 Dec 2011 10:11:37 -0400, David Bremner <david@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@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)