From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Alexander Adolf <alexander.adolf@condition-alpha.com>
Cc: emacs-devel@gnu.org, Thomas Fitzsimmons <fitzsim@fitzsim.org>
Subject: Re: [PATCH] new EUDC backends for ecomplete, and mailabbrev (with ERT tests)
Date: Tue, 16 Aug 2022 21:47:19 -0400 [thread overview]
Message-ID: <jwvv8qreko3.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <8e9c60585677321e437a29215963a908@condition-alpha.com> (Alexander Adolf's message of "Wed, 17 Aug 2022 02:11:21 +0200")
Alexander Adolf [2022-08-17 02:11:21] wrote:
> +To enable the ecomplete backend, first `require' the respective
> +library to load it, and then set the `eudc-server' to localhost in
> +your init file:
[ I think those `...' should be replace with @code{...} or something
like that. ]
I think we should be able to make the setup more intuitive. The most
immediate problem I see is that there's nothing in "set the
`eudc-server' to localhost" which refers to ecomplete, so as a reader
I'm left wondering why that would help.
> +@lisp
> +(require 'eudcb-ecomplete)
> +(eudc-ecomplete-set-server "localhost")
> +@end lisp
It's better to avoid using `require` inside the init file:
- As a general rule, loading an ELisp file should not significantly affect
Emacs's behavior.
- `require` has to load the file right away, slowing down startup.
The second point is moot here, admittedly, since calling
`eudc-ecomplete-set-server` will need eudc-ecomplete anyway (either via
`require` or via autoloading), but still it's better to autoload that
function so the users don't need to `require` the library explicitly.
Even better would be to replace the above with something like:
(setq eudb-foo-bar 'ecomplete)
so the EUDB files don't need to be loaded at startup.
[ FWIW, I also happen to believe that Ecomplete should generally be
enabled by default, so there should be *no* configuration needed at
all for it to work. ]
> +;;; Commentary:
> +;; This library provides an interface to the ecomplete package as
> +;; an EUDC data source.
> +
> +;;; Usage:
> +;; To load the library, first `require' it:
> +;;
> +;; (require 'eudcb-ecomplete)
See above.
> +;; In the simplest case then just use:
> +;;
> +;; (eudc-ecomplete-set-server "localhost")
Why have a dummy argument?
> +(defvar eudc-ecomplete-attributes-translation-alist
> + '((email . mail))
> + "See `eudc-protocol-attributes-translation-alist'.
> +The back-end-specific attribute names are used as the \"type\" of
> +entry when searching, and they must hence match the types you use
> +in your ecmompleterc database file.")
^^^^^^^^^^^^
typo
> +;; hook ourselves into the EUDC framework
> +(eudc-protocol-set 'eudc-query-function
> + 'eudc-ecomplete-query-internal
> + 'ecomplete)
> +(eudc-protocol-set 'eudc-list-attributes-function
> + nil
> + 'ecomplete)
[ Sounds like EUDC could make use of `cl-generic` :-) ]
> +(defun eudc-ecomplete-query-internal (query &optional _return-attrs)
> + "Query `ecomplete' with QUERY.
> +QUERY is a list of cons cells (ATTR . VALUE). Since `ecomplete'
> +does not provide attributes in the usual sense, the
> +back-end-specific attribute names in
> +`eudc-ecomplete-attributes-translation-alist' are used as the
> +KEY (that is, the \"type\" of match) when looking for matches in
> +`ecomplete-database'.
> +
> +RETURN-ATTRS is a list of attributes to return, defaulting to
> +`eudc-default-return-attributes'."
> + (ecomplete-setup)
> + (let ((email-attr (car (eudc-translate-attribute-list '(email))))
Why do we ignore `return-attrs` and hardcode `email` instead (and make
the docstring lie in the process)?
> + ;; special case email: try to decompose
As a convention we like treat our comments with respect; granting them
the same capitalization and punctuation we'd use in normal text.
> +(eudc-register-protocol 'ecomplete)
I think it would be good to have `ecomplete` registered as a supported
protocol before this file is loaded.
Oh, and thanks for the tests.
I haven't looked at the mailabbrev patch, sorry.
Stefan
next prev parent reply other threads:[~2022-08-17 1:47 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-17 0:11 [PATCH] new EUDC backends for ecomplete, and mailabbrev (with ERT tests) Alexander Adolf
2022-08-17 1:47 ` Stefan Monnier [this message]
2022-11-09 2:27 ` Thomas Fitzsimmons
2022-08-18 13:14 ` Thomas Fitzsimmons
2022-10-15 14:32 ` Thomas Fitzsimmons
2022-11-28 21:28 ` Alexander Adolf
2022-11-29 0:46 ` Thomas Fitzsimmons
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvv8qreko3.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=alexander.adolf@condition-alpha.com \
--cc=emacs-devel@gnu.org \
--cc=fitzsim@fitzsim.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).