[Top][All Lists]

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

Re: [PATCH] `affixation-function`: Allow only three-element lists

From: Daniel Mendler
Subject: Re: [PATCH] `affixation-function`: Allow only three-element lists
Date: Sun, 25 Apr 2021 23:04:15 +0200

On 4/25/21 10:34 PM, Juri Linkov wrote:
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.
Okay, fair enough. I am fine if the `cl-assert` is removed from the patch. The other changes should be kept though, such that we do not violate the more restricted specification. Other completion UIs may not support the two-element affixations which are then still accidentally allowed by the default completion UI. The `cl-assert` is just a cheap check to ensure that no violating affixation functions are accidentally reintroduced. But you are right that this is not fail-safe. Do you want me to send an updated patch with the `cl-assert` removed?


reply via email to

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