ecomplete: the Emacs contact manager you were looking for

Okay, I can't know what you are looking for, but I myself just wanted a simple way to store email addresses and insert them with completion when composing new messages. BBDB and the like are way too fancy for me. It turns out BBDB has a poor cousin, called 'ecomplete'. To activate it, you just need to (setq message-mail-alias-type 'ecomplete) Alternatively, if you prefer to use the standard completion-at-point instead of ecomplete's handicrafted UI (works well with Orderless or flex completion styles) you can use the following: (ecomplete-setup) (add-hook 'message-sent-hook 'message-put-addresses-in-ecomplete) (setq message-mail-alias-type nil message-expand-name-standard-ui t) (I wish the above was less hacky to get working, but alas). This is ridiculously obscure stuff. I could only find ecomplete after imagining the feature and starting to study the places you need to understand to implement it... So I hope this is a helpful hint for some people :-). EDIT — As pointed out below by u/gusbrs, the following setup code for use with the standard completion UI also works and is cleaner: (setq message-mail-alias-type 'ecomplete message-self-insert-commands nil message-expand-name-standard-ui t) ​

Damnit! Something else to distract me from what I should be doing. I am giving myself forewarning... (setq elfeed-feeds '( ;; tech ("https://www.reddit.com/r/emacs.rss" NSFW tech reddit emacs VNSFW)))

Yes, ecomplete is the minimalist addressbook I always wanted! I think I discovered it when I was starting to write Embark: I grepped the Emacs sources for calls to completing-read that did use the category metadata. But I didn't start using it until quite recently, since I had a functioning system first with BBDB and later with EBDB (which is a rewrite of BBDB using EIEIO). I switched to EBDB just because it was easier for me to set it up to use completion-at-point (I still don't know if that's possible with BBDB). I'm very happy with ecomplete now, I mostly just need the completion and automatic storing of addresses I write to, as configured in your post. But occasionally I want to remove an address or manually add one, so I wrote a [couple of commands to do that](https://github.com/oantolin/emacs-config/blob/master/my-lisp/ecomplete-extras.el) which I bind in `embark-email-map` to `+` (for adding) and `\` (for removing). I don't think I've used these commands directly, always as Embark actions. When I want to add an email to ecomplete I usually have it written in some buffer already. And the command to remove an email I've only ever used from the ecomplete completion interface or from a message buffer after mistakenly having inserted it and realized that's an old address I'll never use again.

Personally I use org-contact, it's not hyper-nice, but since I store a note a contact with various things relative to the contact is an effective way to group information in some usable way, notmuch-addrlookup add up for contacts I miss in org-contacts but to exists as from:/to: in my maildir :-) The main issue still remain interoperability (vcard import/export and/or LDAP/ldif support), without something really usable contacts remain useful just for mail completion, birthdays&similar on org-agenda but not really "modern days contacts"... However thanks to letting me discover another part of Emacs :-)

When I last checked, it \`org-contacts\` was too outdated to run on a recent Emacs. But I think it would be nice to have a little competion-at-point function for emails stored in an org file.

So far works for me, I'm still on 27.2 because I simply deploy the Emacs I have in NixOS pkgs, not tracking the upstream except for experimenting new feature when announced (just to see and be prepared). It's not fast given the mass of org-notes I have and the unoptimized way I use them for contacts [1] but work at least for completion for composing mail. I've tried org-vcard etc for export but seen the outcome I really do not go past the mere address completion... I hope new new trend/fashion for notes will push some ideas toward a DB-like information management (something happen, still not there though) :-) [1] I simply pass all notes in my org(-roam) directory, so far I've not created a subdir dedicated to contacts or select them otherwise to speed-up, but since the slowness happen essentially only at Emacs boot (org-agenda-files are also all my files, so they are all preloaded) and I'm on EXWM I do not care much, perhaps in the future...

I use the latest emacs compile from git master (update just yesterday) with `pgtk` and `native-comp` and `org-contacts` works without issues for me. I remember I saw some issue in the past due to some function from the deprecated `cl` library being used and this lead to errors during compilation, so I had to add a compile-time require, but I think this is solved now and it uses `cl-lib` only. It might be worth noting that since org 9.5, `org-contrib` (of which `org-contacts` is part of) resides in a separate git repository from org-mode, so make sure you use the latest version from there.

Logged in just to leave a thank you note. Thank you! Cool stuff, I had no idea it existed, even better that it's built-in, and at the sweet spot of being simple and getting the job done.

u/oantolin, I did "borrow" your helper functions. Thank you!

Is this the file you refer to? I assume not, since it even has some lexical-lets in it. https://git.sr.ht/~bzg/org-contrib/blob/master/lisp/org-contacts.el

Ah, u/astoff1, you may get rid of your hook and the direct call to `ecomplete-setup` if you set `message-self-insert-commands` to nil. ;-) (This will disable the echo area hint but still let `(setq message-mail-alias-type 'ecomplete)` do its job of setting things up).

Nice, I added this as a note to the original post.

Yes it is and oh now and upps, my mistake, seems I answered prematurely, seems that it still contains the deprecated code parts 🙈. However, I clearly remember that in the past I had seen an error message when auto-completing contacts in mu4e. A workaround was to add a `(eval-when-compile (require 'cl))`. However, currently the last time I pulled and build org-contrib with straight I didn't include this line and somehow it work. Somehow, it seems that `obsolete/cl.el` is somehow now automatically included when compiling, but tbh I have now idea 🤷. I feel like this shouldn't be too difficult to fix by just requiring lexical bindings for that file via prop-line and just use regular `let` instead, but I don't understand emacs lisp and possible caveats of lexical binding well enough that I have the confidence to do this change by myself.

I just tried this, and I'm confused about what it's supposed to achieve. I sent some test mail and it added those addresses to its address book file; and now when I start typing one of those recipient addresses I see all matching addresses from that file in the echo area, with the matching portion of the text highlighted. So far so good, but... I have no idea at all how to actually perform completion using this. None of the normal completion bindings I've tried are making use of any of this; so I still have to either type the entire address manually, or use completion facilities which were already there without ecomplete. How does one invoke "ecomplete's handicrafted UI" in any interactive sense? I tried from `emacs -Q` in case my config was messing with the defaults, but I see the same from there.

Well I figured it out by guess-work -- if you type `M-n` then it 'focuses' on the echo area completions, and at that point you can cycle through them with additional `M-n` or `M-p` (or cursor up/down), and select with `RET`. `M-n` runs the command `message-display-abbrev` which wasn't a super-obvious solution to me. This also means that when you can see in the echo area that there's only one possibility, it still takes two keystrokes to complete it, which is a bit annoying. I feel like `M-n` could auto-select in that situation, and avoid the need to `RET` on the only possible choice.

Contribute those upstream?

I doubt there'd be any interest.

I'm interested. And /u/gusbrs was interested. And making things better makes things better. I think these seem like pretty obvious/important features for any address book, no matter how minimal, so I'd be surprised if there's no other interest in *some* kind of solution.

Well, that code only handles emails, and ecomplete can complete all kinds of data. Also my code pretends you can parse emails with simple-minded regexps! I think it would need beefing up as well as plenty of generalization before it could even be considered. If you want to bring this up on the mailing list and suggest my code as a starting point, please go ahead. My code is under GPL 3.0 and I've already signed the copyright assignment to the FSF (I have a couple of packages in GNU ELPA).

Thank you for this. Very helpful; I had not been aware of ecomplete and it does do the job nicely of auto-populating a list of email addresses and completing from that list. What I would love to see is a combination of ecomplete and mailabbrev to enable both auto-populating the list of addresses and the use of aliases for some common addresses. It would be great if SPC or "," would invoke mailabbrev. Ummm, should be possible... (time to go procastinate on the actual work I should be doing... ;-)).

Short, inelegant, solution is to manually invoke `mail-abbrev-insert-alias`, which is probably good enough for me while I get used to `ecomplete`.