From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Re: Extending the ecomplete.el data store. Date: Sun, 04 Feb 2018 17:54:13 -0600 Message-ID: <87efm071lm.fsf@red-bean.com> References: <87fu6hcm9r.fsf@red-bean.com> Reply-To: Karl Fogel NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1517788355 14077 195.159.176.226 (4 Feb 2018 23:52:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 4 Feb 2018 23:52:35 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 05 00:52:31 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eiU57-0002og-4f for ged-emacs-devel@m.gmane.org; Mon, 05 Feb 2018 00:52:21 +0100 Original-Received: from localhost ([::1]:55511 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eiU78-0004Vt-AZ for ged-emacs-devel@m.gmane.org; Sun, 04 Feb 2018 18:54:26 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57269) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eiU70-0004VP-ER for emacs-devel@gnu.org; Sun, 04 Feb 2018 18:54:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eiU6z-0004QR-7l for emacs-devel@gnu.org; Sun, 04 Feb 2018 18:54:18 -0500 Original-Received: from mail-io0-x234.google.com ([2607:f8b0:4001:c06::234]:45235) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eiU6z-0004P2-1E for emacs-devel@gnu.org; Sun, 04 Feb 2018 18:54:17 -0500 Original-Received: by mail-io0-x234.google.com with SMTP id p188so28447046ioe.12 for ; Sun, 04 Feb 2018 15:54:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:reply-to:date:in-reply-to :message-id:user-agent:mime-version; bh=mwnpeID6jzOYCk9cYL709ulezIYPMCVC9ys765i4w6I=; b=dFhjVQ2Z9vqmUGiGwCnw5uEzYeFUfAdqjvodMczPNhyHBsNo3MZxpj8x5bAhaA4HBF wrgdyGCpOtwWsapadIAH69myR1f/VZFYVoz5yk8wkjfGTeb3d2yjdzRO3VhnGvcYOj8Z 4gL4YDsccDivKurpJ0+yDhluAdVPkXTkKYMwnjDLg8gZ5ks2/Nyy/M5/Wzn+vcLxQhb8 reCwQRHtDmHLz6ROAs6SvmJLeS1atvxdDTa7tr/qoDimIjrcySnnpUC6TAhMBySvrBCV wsruLcP3Rw3y18BmrtIwREWCd0O3fC6ozcz8wUIQtDsM8qBRN0J45z5k15SYrEvoQdNX /oww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:reply-to :date:in-reply-to:message-id:user-agent:mime-version; bh=mwnpeID6jzOYCk9cYL709ulezIYPMCVC9ys765i4w6I=; b=QFMLzWdO+f/cuLqeNHm+yHgf6JwyhcJdFfiuKwRtOvSddls6N8RbJsj7GgqqRKhaqE v41xx6fU95eB9baA7oJeGG/ain7oc2Hcw4Gk5BhpJr+MC8o55ic6xPHNpLGn5KKxPobC Lnzenkzozvcr/3KiKKrpnE+c1as9k7rp2smmViA3MjoGfxWhNQrUTPgjcqkc2Ak+Unz7 jpMv0a7wd9qR5BQVRtP7LlBSjG86j65iORXiTQrja1oZLnaEonbU2Gyo+GjKA0qrPXEO 52pj/V8QYAbb39MZYKZypLN8kcROyK7AeZ7hviMYPPO76yUqvTWWGxw/+FOtwEgRtwXy xiEw== X-Gm-Message-State: AKwxytd9CYxIn8oofISvsagsKovqQcLdMwD9bid/2l7MklT7kjDb7T3T ffwAJNGklI6KxD9gzpELI+NjhQ== X-Google-Smtp-Source: AH8x227jEHXVPt7oDYmJBVihlInHEGiS5BHV9bu6yXmYdb3c8NlyzvyP6Nu26hqvxm2IILqxuKWE0Q== X-Received: by 10.107.168.217 with SMTP id e86mr39328260ioj.14.1517788455768; Sun, 04 Feb 2018 15:54:15 -0800 (PST) Original-Received: from floss ([2602:306:3707:da30:7cc0:9e41:be2:69fe]) by smtp.gmail.com with ESMTPSA id z131sm2506670itb.4.2018.02.04.15.54.14 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 04 Feb 2018 15:54:15 -0800 (PST) In-Reply-To: (Stefan Monnier's message of "Sun, 04 Feb 2018 17:33:50 -0500") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4001:c06::234 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:222530 Archived-At: Stefan Monnier writes: >FWIW, I recently installed a completion-table for ecomplete together >with a ecomplete completion-at-point-function for message.el, which >together let you use the ecomplete database for TAB completion as well >as for company-mode ("tooltip-like"). That's good to know, thanks. All the more reason to centralize on a unified database of email addresses, containing all the information anyone might want, and have packages build functionality around that. >> (KEY ; string: downcased email addr >> ((VARIANT ; string: case-preserving address w/ real name >> (TYPE ; symbol: `mail', etc >> ('last-sent LAST_TIME_SENT_TO) ; int: seconds since epoch >> ('last-recv LAST_TIME_RECEIVED_FROM_TO) ; int: seconds since epoch >> ('sent-count SENT_COUNT) ; int: total times sent >> ('recv-count RECEIVED_COUNT) ; int: total times received >> ) >> ...further TYPEs could go here... >> ) >> ...further VARIANTs here... >> ) >> ...[reserved, in case we ever need something other than VARIANTs]... >> ) > >Can you show an example where the presence of multiple variants lets you >do something you can't do with the single variant? >I'm not sure I understand the benefits. Sure. It's common to have these kinds of variants for one email address (note how subtle case variations can even appear in only the address portion): "Wutherington, Joanna - NYC" "Wutherington, Joanna" "JOANNA WUTHERINGTON" "Joanna Wutherington" "Joanna Wutherington" "joanna wutherington" "J. Wutherington" "Joanna W." "Joanna W" "joannaw@example.com" ... etc, etc ... (I've seen all of those variants before, and some addresses show up in my completion database with a significant number of those variants. Oh, and sometimes they have double quotes and sometimes they don't. Fun.) There are many factors that can cause this kind of variation. For example, when one is sending mail to that recipient, one might compose the email this way... "Joanna Wutherington" ...even though one has never actually received mail from them with that exact form of the address. Maybe one copied-and-pasted the address from other sources, or whatever. The point is, that might be the route by which that particular form gets into the completion database. So the question is, when completing an address, which variant does the user want? Mailaprop tries to figure out the "best" variant of a given address, and assign that variant a higher score than any of the other variants, so that the "best" one shows up higher in the completion list than any of those others. The algorithm Mailaprop uses for determining "best" is not important here. The point is just that in order to have an algorithm at all, the inputs have to be available. Thus, the reason to have a format that preserves all these variants is so that packages (like ecomplete and mailaprop) can have enough information to try out interesting algorithms for autofill behavior. As far as I know, ecomplete just always remembers the most-recently-seen variant. That probably works well for most cases, but there will be times when "Joanna Wutherington" gets replaced by (say) "joannaw@example.com" ...yet the user would almost certainly prefer the former. Mailaprop preserves all the variants and scores them in order to avoid that situation. >AFAICT the main difference here compared to the ecompleterc format is >that we impose the notion of "sending" and "receiving", whereas the >ecompleterc could conceivably be used for things fundamentally unrelated >to sending/receiving messages (e.g. completion of file names, say). Ah, yes -- so could mailaprop, come to think of it. However, the TYPE indicator can govern what's in the variant list. In other words, we can adjust the proposal so that the inner format is just for when TYPE == `mail'. The inner format for other types has yet to be determined, because we don't know yet what kind of inputs they'll need to make good autofill behavior possible. >I haven't used ecomplete very much so far, but I've noticed some issues >which I think are linked to having multiple Emacs sessions use it at the >same time. I haven't investigated enough to be sure, but in any case >it's a use case that should be kept in mind. That's probably related only to how ecomplete generates its database; I don't think it affects the format of the database. I.e., if one wants to be able to "splice new things in" to the database in memory, and write the database out at the end of the session, that's not significantly harder with the proposed new format than with the old one, and any multiple-session or cross-machine synchronization/conflict problems are the same in both cases. >[ And along vaguely related lines, I'd really like if the ecompleterc > database could be somehow shared between my different machines. > E.g. by arranging for git-merge to "do-the-right-thing" on it, or by > storing (a copy of) it in IMAP. ] I haven't thought much about that, because I solve that problem out-of-band right now: my mailaprop database is under version control and gets automatically sync'd across all the machines I work on (and the same would be true of .ecompleterc if I were using that). I agree it would be a good thing if Emacs solved that automagically, as long as it were truly reliable. Best regards, -Karl