Return-Path: X-Original-To: notmuch@notmuchmail.org Delivered-To: notmuch@notmuchmail.org Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 613AC421191 for ; Sat, 14 Jan 2012 16:05:37 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0S5G8lKSaSED for ; Sat, 14 Jan 2012 16:05:36 -0800 (PST) Received: from dmz-mailsec-scanner-5.mit.edu (DMZ-MAILSEC-SCANNER-5.MIT.EDU [18.7.68.34]) by olra.theworths.org (Postfix) with ESMTP id C1149421176 for ; Sat, 14 Jan 2012 16:05:36 -0800 (PST) X-AuditID: 12074422-b7fd66d0000008f9-8f-4f1218502875 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id E6.53.02297.058121F4; Sat, 14 Jan 2012 19:05:36 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id q0F05aJc020421; Sat, 14 Jan 2012 19:05:36 -0500 Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91]) (authenticated bits=0) (User authenticated as amdragon@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id q0F05YLH026525 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Sat, 14 Jan 2012 19:05:35 -0500 (EST) Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.77) (envelope-from ) id 1RmDbH-0002Id-Iv; Sat, 14 Jan 2012 19:05:31 -0500 Date: Sat, 14 Jan 2012 19:05:31 -0500 From: Austin Clements To: Jameson Graef Rollins Subject: Re: [PATCH v2 2/3] lib: Add support for automatically excluding tags from queries Message-ID: <20120115000531.GF1801@mit.edu> References: <1326258173-21163-1-git-send-email-amdragon@mit.edu> <1326496024-14403-1-git-send-email-amdragon@mit.edu> <1326496024-14403-3-git-send-email-amdragon@mit.edu> <87zkdpsvln.fsf@servo.finestructure.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87zkdpsvln.fsf@servo.finestructure.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHKsWRmVeSWpSXmKPExsUixG6nohsgIeRv8PyrpEXTdGeLPfu8LK7f nMnswOxx9zSXx637r9k9nq26xRzAHMVlk5Kak1mWWqRvl8CV8f74G5aCCWIV718cYG1gfCbY xcjJISFgIrF86gt2CFtM4sK99WxdjFwcQgL7GCUmr1zACOFsYJQ48PIFC0iVkMBJJon9t+Mh EkuAEmvXMIIkWARUJTZ1vGICsdkENCS27V8OFhcRMJPo+fIHzGYW0JF4ffg90CAODmGBGIlT b4VAwrwC2hKLp19kh5h5k1Hi5qaZjBAJQYmTM5+wQPSqS/yZd4kZpJdZQFpi+T8OiLC8RPPW 2cwgNqeAqcSlp/vZQGxRARWJKSe3sU1gFJ6FZNIsJJNmIUyahWTSAkaWVYyyKblVurmJmTnF qcm6xcmJeXmpRbqmermZJXqpKaWbGMFR4aK0g/HnQaVDjAIcjEo8vIU5Av5CrIllxZW5hxgl OZiURHnXigv5C/El5adUZiQWZ8QXleakFh9ilOBgVhLhXcAKlONNSaysSi3Kh0lJc7AoifOq a73zExJITyxJzU5NLUgtgsnKcHAoSfC+BhkqWJSanlqRlplTgpBm4uAEGc4DNPwZSA1vcUFi bnFmOkT+FKMux8m1V84xCrHk5eelSonz7gIpEgApyijNg5sDS2avGMWB3hLmXQdSxQNMhHCT XgEtYQJaUpbCB7KkJBEhJdXAuGLXL27TEK/Jjt1FUSd+qB5gfPRE96PiejFdoTJO66BFd7hP rWB+yPZj39Me7YT0SGXWDzqmniw/1m0N1I36U/zrlqPIt2m6wkFPmMr637DOS9BxFOVTmuYd 0V6iHmy0oHRZc6ztlqSsuB0aj1bqatovsVxpmRgiLhb+8Ostp5Cw5XM1JZiUWIozEg21mIuK EwFJWWkXQQMAAA== Cc: notmuch@notmuchmail.org X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2012 00:05:37 -0000 Quoth Jameson Graef Rollins on Jan 14 at 3:38 pm: > It looks like something in this patch is causing the following build > warning: > > CXX -O2 lib/query.o > lib/query.cc:26:8: warning: ‘_notmuch_query’ declared with greater visibility than the type of its field > ‘_notmuch_query::exclude_terms’ [-Wattributes] > > However, I can't quite figure out what's causing it. The problem is that notmuch_query_t is a "visible" symbol because the type is declared (though not defined) in lib/notmuch.h. The actual definition is tucked away in lib/query.cc, but GCC doesn't seem to care. I added a field of type notmuch_string_list_t to the struct's definition, but notmuch_string_list_t is declared between the "hidden" pragmas in lib/notmuch-private.h because the type is private to the library. This field with a hidden type in a visible type is what GCC is complaining about. I'm rather confused by the whole type visibility thing since type symbols aren't linkable anyway. However, while puzzling over how you could possibly use hidden types if they can only be used in other hidden types, I discovered that Carl had solved this exact problem last May in d5523ead by adding a visibility("default") attribute to the offending hidden type. > > +void > > +notmuch_query_add_tag_exclude (notmuch_query_t *query, const char *tag) > > +{ > > + char *term = talloc_asprintf (query, "%s%s", _find_prefix ("tag"), tag); > > + _notmuch_string_list_append (query->exclude_terms, term); > > +} > > This is really not an issue with this patch at all, and it should NOT > prevent it from being applied, but this came up briefly on IRC and I'm > curious, so I'll ask about it here. > > Are terms ALWAYS lower cased? If not, it seems to me it's possible to > have an indexed term 'Kspam' that would get confused with the term > 'spam' prefixed with the keyword prefix 'K' (which we use for tags). > Maybe this degeneracy is broken by the query parser somehow (or maybe by > the fact that tags are boolean terms?), but I wonder if it's not safer > to use the built-in xapian prefix separator ':', ie: > > ... talloc_asprintf (query, "%s:%s", _find_prefix ("tag"), tag); > > I guess fixing that globally would require a database rebuild... We discussed this on IRC, but to summarize for the list, the tag prefix is a single character, so Xapian's ':' rule doesn't apply. There are several places where we *do* get this wrong and use a multi-character term prefix with a term that may start with a capital letter but they're all terms you can't search anyway and, unless I'm mistaken, we're completely consistent about where we violate or do not violate the ':' rule. > Ok, that's totally just an aside, and should not be a blocker for this > patch. > > jamie.