From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Sergio Durigan Junior Newsgroups: gmane.emacs.bugs Subject: bug#19678: [PATCH] EUDC does not support BBDB 3.x Date: Fri, 06 Feb 2015 20:43:32 -0500 Message-ID: <87d25mcx8b.fsf@sergiodj.net> References: <87mw57hhrd.fsf@sergiodj.net> <87lhkpjrg3.fsf@sergiodj.net> <8761btjh1m.fsf@sergiodj.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1423273456 8453 80.91.229.3 (7 Feb 2015 01:44:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 7 Feb 2015 01:44:16 +0000 (UTC) Cc: 19678@debbugs.gnu.org To: Thomas Fitzsimmons Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Feb 07 02:44:11 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YJuRP-0002LH-78 for geb-bug-gnu-emacs@m.gmane.org; Sat, 07 Feb 2015 02:44:11 +0100 Original-Received: from localhost ([::1]:51155 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJuRO-0001D4-CY for geb-bug-gnu-emacs@m.gmane.org; Fri, 06 Feb 2015 20:44:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42490) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJuRK-0001C1-Jz for bug-gnu-emacs@gnu.org; Fri, 06 Feb 2015 20:44:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YJuRG-0001el-Pl for bug-gnu-emacs@gnu.org; Fri, 06 Feb 2015 20:44:06 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44722) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJuRG-0001ed-NK for bug-gnu-emacs@gnu.org; Fri, 06 Feb 2015 20:44:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YJuRG-0000Kh-57 for bug-gnu-emacs@gnu.org; Fri, 06 Feb 2015 20:44:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Sergio Durigan Junior Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 07 Feb 2015 01:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19678 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 19678-submit@debbugs.gnu.org id=B19678.14232734211245 (code B ref 19678); Sat, 07 Feb 2015 01:44:02 +0000 Original-Received: (at 19678) by debbugs.gnu.org; 7 Feb 2015 01:43:41 +0000 Original-Received: from localhost ([127.0.0.1]:35962 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YJuQu-0000K0-Jo for submit@debbugs.gnu.org; Fri, 06 Feb 2015 20:43:41 -0500 Original-Received: from kwanyin.sergiodj.net ([176.31.208.32]:56989) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YJuQq-0000Jm-Tg for 19678@debbugs.gnu.org; Fri, 06 Feb 2015 20:43:38 -0500 X-URL: http://blog.sergiodj.net In-Reply-To: (Thomas Fitzsimmons's message of "Mon, 26 Jan 2015 21:10:23 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:99114 Archived-At: On Monday, January 26 2015, Thomas Fitzsimmons wrote: > Sergio Durigan Junior writes: > >> On Monday, January 26 2015, Thomas Fitzsimmons wrote: >> >>>> Almost there... The patch doesn't work as-is because >>>> 'eudc-bbdb-current-return-attributes' is set to '(firstname lastname >>>> mail) for me when eudc-bbdb-format-record-as-result is called. It means >>>> that, in the while loop, it will try to call eq/memq against 'mail, and >>>> it fails. >>> >>> Hmm, I thought those get converted; in any case, I wasn't seeing that >>> problem. Do you have any customizations of the relevant variables? Do >>> you have my latest EUDC/LDAP changes from master tip? >> >> I am using git HEAD to test and develop, so I think I do have your >> changes. >> >> As for my customizations, I'm almost sure they're the reason for me >> seeing the errors. What I have here is: >> >> (eudc-protocol-set 'eudc-inline-expansion-format '("%s %s <%s>" firstname name mail) >> 'bbdb) > > OK, yes, that explains why you're seeing an error and I'm not. > > Though I can understand why you're doing it this way (see below), I > think calling eudc-protocol-set directly in this case is a > misconfiguration; it bypasses the "defcustom" way of doing things. > Prior to my patches, the way this was supposed to work is that the user > customized eudc-inline-expansion-format using generic EUDC symbols for > the fields. In your case, this would have been: > > (customize-set-variable 'eudc-inline-expansion-format > '("%s %s <%s>" firstname name email)) > > i.e., email not mail, and with no protocol specified. Then EUDC would > translate those to the fields used by the specific backend. Then if you > were using an LDAP server and a BBDB "server", you'd get the same > results from both without having to figure out the "email" field for > each of them. > > All that said, my patches fixed the default to be exactly what you're > configuring. Now you can just remove that line and it'll do exactly > what you want. [ I'm back from the trip. Sorry about the long delay. I confess I had some things to mention/discuss about your reply before leaving, but now I forgot almost all of them. Oh, well... ] Right, thanks for explaining. It indeed makes sense to use EUDC's specific names, instead of BBDB/LDAP/whatever. I will change my configuration to reflect that. >> (eudc-protocol-set 'eudc-inline-query-format '((mail) >> (firstname) >> (lastname) >> (firstname lastname) >> (aka)) >> 'bbdb) > > I also changed this default to be: > > '((email) > (firstname) > (firstname name)) > > The aka is where eudc-protocol-set seems to make most sense; after all, > aka is BBDB-specific. But EUDC backends will just return no results for > fields they don't know about, so it's actually safe to just put aka in > eudc-inline-query-format via customization, without resorting to > eudc-protocol-set. The LDAP backend will ignore it, the BBDB backend > will interpret and attempt it: > > (customize-set-variable 'eudc-inline-query-format '((email) > (firstname) > (name) > (firstname name) > (aka)) > > The manual should maybe explicitly mention this, but then we'd have to > expose all fields from all backends directly to the user for > configuration, which may confuse things even more. > > In general I don't like this aspect of EUDC: how confusing it is to > configure. It's made even worse by the fact that even when configured > properly it can still fail because of bugs. I've tried to simplify the > configuration by providing better defaults, and I'm also trying to fix > the bugs. Thanks a lot for working on EUDC. I agree that it is frustrating to stumble upon bugs every time. >> Also, IMHO, the final patch makes sense to me, even if there are still >> other issues to be fix on EUDC. > > I'd like to keep the attribute symbols "private" in the backends, and > encourage people to use the generic EUDC symbol names instead (plus > hidden extras like aka, if they want) using the standard customization > procedures. In which case the 'net stuff can stay as is in the BBDB > backend. Can you try the configuration changes I've outlined above, > along with 0001-EUDC-Support-BBDB-3.patch, and confirm that they work > for you? > > I'll credit you in the ChangeLog too since we both worked on the patch. > Let me know when your copyright assignment goes through, and I'll push > it after that. All right, thanks a lot. I still haven't received feedback from the FSF, but I believe things are mostly OK since this is just an extension of my existing copyright assignment for GDB/binutils. That being said, I think that, if you want to go ahead and push the patch, it's fine. Otherwise, I will get back to you when I receive FSF's reply. Cheers, -- Sergio GPG key ID: 0x65FC5E36 Please send encrypted e-mail if possible http://sergiodj.net/