From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] `affixation-function`: Allow only three-element lists Date: Sun, 25 Apr 2021 23:34:23 +0300 Organization: LINKOV.NET Message-ID: <87wnsqgl2o.fsf@mail.linkov.net> References: <87h7jujmbn.fsf@mail.linkov.net> <02eb444c-d8e2-8271-1edc-b02b3ce7f64c@daniel-mendler.de> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9913"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) Cc: Stefan Monnier , emacs-devel@gnu.org To: Daniel Mendler Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Apr 25 22:54:50 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lalmE-0002OQ-Kz for ged-emacs-devel@m.gmane-mx.org; Sun, 25 Apr 2021 22:54:50 +0200 Original-Received: from localhost ([::1]:51494 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lalmD-0006Bk-Mw for ged-emacs-devel@m.gmane-mx.org; Sun, 25 Apr 2021 16:54:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47296) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lallL-0005Mt-Ae for emacs-devel@gnu.org; Sun, 25 Apr 2021 16:53:55 -0400 Original-Received: from relay9-d.mail.gandi.net ([217.70.183.199]:46733) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lallJ-0007aG-0c for emacs-devel@gnu.org; Sun, 25 Apr 2021 16:53:54 -0400 X-Originating-IP: 91.129.102.166 Original-Received: from mail.gandi.net (m91-129-102-166.cust.tele2.ee [91.129.102.166]) (Authenticated sender: juri@linkov.net) by relay9-d.mail.gandi.net (Postfix) with ESMTPSA id 1CEB0FF802; Sun, 25 Apr 2021 20:53:46 +0000 (UTC) In-Reply-To: <02eb444c-d8e2-8271-1edc-b02b3ce7f64c@daniel-mendler.de> (Daniel Mendler's message of "Sun, 25 Apr 2021 20:02:39 +0200") Received-SPF: pass client-ip=217.70.183.199; envelope-from=juri@linkov.net; helo=relay9-d.mail.gandi.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:268424 Archived-At: >>> + (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.