emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Extending the ecomplete.el data store.


From: Stefan Monnier
Subject: Re: Extending the ecomplete.el data store.
Date: Sun, 04 Feb 2018 17:33:50 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

> Some context for everyone else: after I wrote mailaprop [2] to do
> prioritized autofill for email addresses, Lars mentioned his
> ecomplete.el, which is part of Emacs.  Ecomplete offers similar
> functionality, although its UI is minibuffer-based rather than
> tooltip-based, and it uses a different address prioritization
> algorithm from mailaprop.

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").

>   (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.

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).

> These two methods of database maintenance are basically compatible.
> In fact, one could use mailaprop's script to generate the database the
> first time, and then depend on ecomplete to keep it up-to-date after
> that.  As long as we document what's going on, and each package uses
> its current defaults, I think we're fine.

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.
[ 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.  ]


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]