From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thomas Fitzsimmons Newsgroups: gmane.emacs.bugs Subject: bug#19678: [PATCH] EUDC does not support BBDB 3.x Date: Mon, 26 Jan 2015 21:10:23 -0500 Message-ID: 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 1422324676 17119 80.91.229.3 (27 Jan 2015 02:11:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 27 Jan 2015 02:11:16 +0000 (UTC) Cc: 19678@debbugs.gnu.org To: Sergio Durigan Junior Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jan 27 03:11:12 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 1YFvcV-0001hh-FL for geb-bug-gnu-emacs@m.gmane.org; Tue, 27 Jan 2015 03:11:11 +0100 Original-Received: from localhost ([::1]:44950 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YFvcU-0000CK-Mf for geb-bug-gnu-emacs@m.gmane.org; Mon, 26 Jan 2015 21:11:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40423) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YFvcQ-0000CE-Rb for bug-gnu-emacs@gnu.org; Mon, 26 Jan 2015 21:11:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YFvcN-0005tX-L4 for bug-gnu-emacs@gnu.org; Mon, 26 Jan 2015 21:11:06 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:38762) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YFvcN-0005tT-HT for bug-gnu-emacs@gnu.org; Mon, 26 Jan 2015 21:11:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YFvcM-00068R-Uq for bug-gnu-emacs@gnu.org; Mon, 26 Jan 2015 21:11:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Thomas Fitzsimmons Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 27 Jan 2015 02:11: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.142232463723546 (code B ref 19678); Tue, 27 Jan 2015 02:11:02 +0000 Original-Received: (at 19678) by debbugs.gnu.org; 27 Jan 2015 02:10:37 +0000 Original-Received: from localhost ([127.0.0.1]:57454 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YFvbw-00067h-B1 for submit@debbugs.gnu.org; Mon, 26 Jan 2015 21:10:36 -0500 Original-Received: from mail-ie0-f177.google.com ([209.85.223.177]:47259) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YFvbr-00067L-52 for 19678@debbugs.gnu.org; Mon, 26 Jan 2015 21:10:32 -0500 Original-Received: by mail-ie0-f177.google.com with SMTP id vy18so12569213iec.8 for <19678@debbugs.gnu.org>; Mon, 26 Jan 2015 18:10:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=/pc2e078xZfZSEVEa7qg0Ef6ILeqjiq1AOCpujZJbqc=; b=TlO/CsOdbyZEJeA6YtOGTSAp/vx9EWZfy+HVOGa4UlfVIxdn0yt4RYMF3TCsP6Dpvj 2oLgMAXbMVsXVaxJCDGaJkkl2nFtc9FwhKxYxXyLxHWE09pRBSfFET1CiSaBBRVP1ikI 2/uGOPY2ph+sooxXT4DTlOZaaYylilNA/NX1WuyymcsjgXsTrSWYvYTP2l7YoHLYPMu1 QPTkB3vbSOdBQ0rGzMuXnGzaz8eYC/qTBKJvFXYu3wkSogwJeielGJYN7GSYTJtbMcQR aPbMp1O4uZTlaUKZROfnj+WSsphQbhTWy6OhPFJ7qkmoROCA/K2O5/QK8NADWajXb/CP EJSw== X-Gm-Message-State: ALoCoQleiJAARgXC3c8gJ/Ww8KT5UDB6B34RMLqqMJRGqvS0PaSuJ6VfJHIJFoK2B7C2XrGJhlj6 X-Received: by 10.42.169.197 with SMTP id c5mr501720icz.72.1422324625368; Mon, 26 Jan 2015 18:10:25 -0800 (PST) Original-Received: from hp-dv5t (69-165-165-189.dsl.teksavvy.com. [69.165.165.189]) by mx.google.com with ESMTPSA id 15sm6935478ioq.8.2015.01.26.18.10.24 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 26 Jan 2015 18:10:24 -0800 (PST) In-Reply-To: <8761btjh1m.fsf@sergiodj.net> (Sergio Durigan Junior's message of "Mon, 26 Jan 2015 17:47:17 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (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:98780 Archived-At: 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. > (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. >> Can we step back a bit and make sure we're doing the same tests? BBDB >> 2.x is tricky because it is provided by the distro, in my case Fedora. >> Let's focus on testing BBDB 3.x so that I can replicate the exact same >> issue that you're seeing. >> >> Can you revert our patch, then: >> >> 1) Checkout and build Emacs revision >> 03a20dc9519616359bfa1b77fd4b31e1963c8bd4 from >> git://git.savannah.gnu.org/emacs.git >> >> This revision has a bunch of my EUDC/LDAP updates in it. > > I'm buying an even newer revision from git, FWIW. > >> 2) Download >> http://download.savannah.gnu.org/releases/bbdb/bbdb-3.1.2.tar.gz >> >> 3) Untar and build the ELPA package: >> export EMACS=/src/emacs >> ./configure && make elpa >> unset EMACS >> >> 4) In the emacs src directory: >> mkdir test-home >> >> 5) HOME=`pwd`/test-home ./emacs -Q >> >> 6) M-x package-install-file >> >> bbdb-3.1.2.tar (the one built in step 3) >> >> 7) M-x bbdb-create >> >> Name: Test User >> Network Address: test@gnu.org >> >> 8) C-x s >> >> to save .bbdb >> >> 9) M-: (eval-after-load "message" >> '(define-key message-mode-map (kbd "TAB") 'eudc-expand-inline)) >> >> 10) M-: (setq debug-on-error 't) >> >> 11) C-x m >> >> 12) Tes[TAB] >> >> (no server, bbdb protocol) >> >> Without my patch, I get: >> >> Debugger entered--Lisp error: (void-function bbdb-record-net) >> (bbdb-record-net record) >> eval((bbdb-record-net record)) >> >> eudc-bbdb-format-record-as-result(["Test" "User" nil nil nil nil nil >> ("test@gnu.org") ((creation-date . "2015-01-26 21:56:26 +0000") >> (timestamp . "2015-01-26 21:56:26 +0000")) ["Test User" "User, Test" >> nil ("test@gnu.org") nil #]]) >> >> mapcar(eudc-bbdb-format-record-as-result (["Test" "User" nil nil nil >> nil nil ("test@gnu.org") ((creation-date . "2015-01-26 21:56:26 >> +0000") (timestamp . "2015-01-26 21:56:26 +0000")) ["Test User" "User, >> Test" nil ("test@gnu.org") nil #]])) >> >> eudc-bbdb-query-internal(((firstname . "Tes")) (firstname lastname >> net)) >> >> eudc-query(((firstname . "Tes")) (firstname lastname net)) >> eudc-expand-inline() >> funcall-interactively(eudc-expand-inline) >> call-interactively(eudc-expand-inline nil nil) >> command-execute(eudc-expand-inline) >> >> With my patch (0001-EUDC-Support-BBDB-3.patch), it works. eudc-query >> gets called with 'net, not 'mail. >> >> If that works for you, can you try to replicate the other error you're >> seeing when my patch is applied, in this same minimal environment, and >> paste the testing steps and the backtrace you get? > > If you insist, I can do this test later (unfortunately I will be very > busy these next days). No need. > Meanwhile, if you could check that my configuration is what triggers > the failure, I'd appreciate. Done. > 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. Thanks, Thomas