From: Juri Linkov <juri@linkov.net>
To: Daniel Mendler <mail@daniel-mendler.de>
Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
Subject: Re: [PATCH] `affixation-function`: Allow only three-element lists
Date: Sun, 25 Apr 2021 23:34:23 +0300 [thread overview]
Message-ID: <87wnsqgl2o.fsf@mail.linkov.net> (raw)
In-Reply-To: <02eb444c-d8e2-8271-1edc-b02b3ce7f64c@daniel-mendler.de> (Daniel Mendler's message of "Sun, 25 Apr 2021 20:02:39 +0200")
>>> + (cl-assert (or (not completions)
>>> + (= 3 (length (car completions))))))
> I am looking at the `affixation-function` from the perspective of how the
> definition can be made as simple/predicatable as possible for the API user
> since there are other completion UIs and many completion tables which will
> make use of this. I treat the completion UI behind the API as a blackbox.
I completely agree that for `affixation-function` part of
the API is would be cleaner to document the input data as
only candidate + prefix + suffix.
But I don't agree with `cl-assert`. It looks too odd.
Why to validate that the length of the first candidate is 3?
Why not to validate than the length of every candidate
is not more than 3? Why not to validate that there are no nils
in the list? Why not to validate there are only strings? Etc.
IOW, I think it's responsibility of the API user to provide valid data
as documented.
next prev parent reply other threads:[~2021-04-25 20:34 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-25 0:39 [PATCH] `affixation-function`: Allow only three-element lists Daniel Mendler
2021-04-25 17:46 ` Juri Linkov
2021-04-25 18:02 ` Daniel Mendler
2021-04-25 20:34 ` Juri Linkov [this message]
2021-04-25 21:04 ` Daniel Mendler
2021-04-27 16:45 ` Juri Linkov
2021-04-27 17:40 ` Daniel Mendler
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=87wnsqgl2o.fsf@mail.linkov.net \
--to=juri@linkov.net \
--cc=emacs-devel@gnu.org \
--cc=mail@daniel-mendler.de \
--cc=monnier@iro.umontreal.ca \
/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).