ca/43af5fe1a7b652d56f6aff17c168b1d504b3c7

   1 Return-Path: <david@tethera.net>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5  by arlo.cworth.org (Postfix) with ESMTP id 1E9AD6DE1B56\r
   6  for <notmuch@notmuchmail.org>; Wed,  2 Sep 2015 18:13:25 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at cworth.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: 0.114\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=0.114 tagged_above=-999 required=5 tests=[AWL=0.114]\r
  12  autolearn=disabled\r
  13 Received: from arlo.cworth.org ([127.0.0.1])\r
  14  by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15  with ESMTP id hgFK-dBBJ5Bc for <notmuch@notmuchmail.org>;\r
  16  Wed,  2 Sep 2015 18:13:23 -0700 (PDT)\r
  17 Received: from gitolite.debian.net (gitolite.debian.net [87.98.215.224])\r
  18  by arlo.cworth.org (Postfix) with ESMTPS id D37D96DE1B51\r
  19  for <notmuch@notmuchmail.org>; Wed,  2 Sep 2015 18:13:22 -0700 (PDT)\r
  20 Received: from remotemail by gitolite.debian.net with local (Exim 4.80)\r
  21  (envelope-from <david@tethera.net>)\r
  22  id 1ZXJ4s-0004iZ-U2; Thu, 03 Sep 2015 01:12:34 +0000\r
  23 Received: (nullmailer pid 17442 invoked by uid 1000); Thu, 03 Sep 2015\r
  24  01:12:14 -0000\r
  25 From: David Bremner <david@tethera.net>\r
  26 To: Rob Browning <rlb@defaultvalue.org>, notmuch@notmuchmail.org\r
  27 Subject: Re: [PATCH 1/1] Store and search for canonical Unicode text [WIP]\r
  28 In-Reply-To: <1440951676-17286-1-git-send-email-rlb@defaultvalue.org>\r
  29 References: <1440951676-17286-1-git-send-email-rlb@defaultvalue.org>\r
  30 User-Agent: Notmuch/0.20.2+60~gcb08a2e (http://notmuchmail.org) Emacs/24.5.1\r
  31  (x86_64-pc-linux-gnu)\r
  32 Date: Wed, 02 Sep 2015 22:12:14 -0300\r
  33 Message-ID: <87fv2we26p.fsf@maritornes.cs.unb.ca>\r
  34 MIME-Version: 1.0\r
  35 Content-Type: text/plain; charset=utf-8\r
  36 Content-Transfer-Encoding: quoted-printable\r
  37 X-BeenThere: notmuch@notmuchmail.org\r
  38 X-Mailman-Version: 2.1.18\r
  39 Precedence: list\r
  40 List-Id: "Use and development of the notmuch mail system."\r
  41  <notmuch.notmuchmail.org>\r
  42 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  43  <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  44 List-Archive: <http://notmuchmail.org/pipermail/notmuch/>\r
  45 List-Post: <mailto:notmuch@notmuchmail.org>\r
  46 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  47 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  48  <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  49 X-List-Received-Date: Thu, 03 Sep 2015 01:13:25 -0000\r
  50 \r
  51 Rob Browning <rlb@defaultvalue.org> writes:\r
  52 \r
  53 >\r
  54 > Before this change, notmuch would index two strings that differ only\r
  55 > with respect to canonicalization, like to=CC=81ken and t=C3=B3ken, as sep=\r
  56 arate\r
  57 > terms, even though they may be visually indistinguishable, and do (for\r
  58 > most purposes) represent the same text.  After indexing, searching for\r
  59 > one would not find the other, and which one you present to notmuch\r
  60 > when you search depends on your tools.  See test/T570-normalization.sh\r
  61 > for a working example.\r
  62 \r
  63 One way to break this up into more bite sized pieces would be to first\r
  64 create one or more tests that fail with current notmuch, and mark those\r
  65 as broken.\r
  66 \r
  67 > Up to now, notmuch has let Xapian handle converting the incoming bytes\r
  68 > to UTF-8.  Xapian treats any byte sequence as UTF-8, and interprets\r
  69 > any invalid UTF-8 bytes as Latin-1.  This patch maintains the existing\r
  70 > behavior (excepting the new canonicalization) by using Xapian's\r
  71 > Utf8Iterator to handle the initial Unicode character parsing.\r
  72 \r
  73 Can you explain why notmuch is the right place to do this, and not\r
  74 Xapian? I know we talked back and forth about this, but I never really\r
  75 got a solid sense of what the conclusion was. Is it just dependencies?\r
  76 \r
  77 > And because when the input is already UTF-8, it just blindly converts\r
  78 > from UTF-8 to Unicode code points, and then back to UTF-8 (after\r
  79 > canonicalization), during each pass.  There are certainly\r
  80 > opportunities to optimize, though it may be worth discussing the\r
  81 > detection of data encodings more broadly first.\r
  82 \r
  83 It seems plausible to specify UTF-8 input for the library, but what\r
  84 about the CLI? It seems like the canonicalization operation increases\r
  85 the chance of mangling user input in non-UTF-8 locales.\r
  86 \r
  87 > FIXME: what about existing indexed text?\r
  88 \r
  89 I suppose some upgrade code to canonicalize all the terms? That sounds\r
  90 pretty slow.\r
  91 \r
  92 > ---\r
  93 >\r
  94 >  Posted for preliminary discussion, and as a milestone (it appears to\r
  95 >  mostly work now).  Though I doubt I'm handling things correctly\r
  96 >  everywhere notmuch-wise, wrt talloc, etc.\r
  97 \r
  98 I really didn't look at the code very closely, but there were a\r
  99 surprising number of calls to talloc_free. But those kind of details can\r
 100 wait.\r
 101 \r
 102 \r