From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Mendler Newsgroups: gmane.emacs.devel Subject: Re: 29.0.60; keymap-local-set and keymap-global-set became less strict Date: Wed, 1 Feb 2023 14:13:25 +0100 Message-ID: <137753af-777d-2da3-c111-7e2d414633f1@daniel-mendler.de> References: <5876987d-2479-f512-5767-218c8c16a909@daniel-mendler.de> <875ycngyji.fsf@gnus.org> <87zg9zvzuc.fsf@gmail.com> <831qna3frm.fsf@gnu.org> <87mt5yogct.fsf@gmail.com> <83y1pi1wz4.fsf@gnu.org> <87ilgmodk4.fsf@gmail.com> <83mt5y1r5u.fsf@gnu.org> <87bkmdo8e4.fsf@gmail.com> <831qn91qo0.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33753"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, emacs-devel@gnu.org, monnier@iro.umontreal.ca To: Eli Zaretskii , Robert Pluim Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Feb 01 14:14:26 2023 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 1pNCwU-0008b2-1k for ged-emacs-devel@m.gmane-mx.org; Wed, 01 Feb 2023 14:14:26 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pNCw2-0002LW-Aa; Wed, 01 Feb 2023 08:13:58 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pNCvy-0002Hp-An for emacs-devel@gnu.org; Wed, 01 Feb 2023 08:13:54 -0500 Original-Received: from server.qxqx.de ([2a01:4f8:121:346::180] helo=mail.qxqx.de) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pNCvt-0002Sm-22; Wed, 01 Feb 2023 08:13:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Snzs9KcIqgF0GsPeaDowmQsy+vAR/64l8Y34gSW7tvQ=; b=I0gs1VwT4aLzLBPopst4JeYh+s Tc1Ep4BaDhjLwkSSeJ/04yQr1WKnc9kIEnAl4uzNTXx0abRtCfVThJ/adCRCs5w9l7yEWlOv3VACP sHqwwbk3rd6L89tGSNP7QHZicFWf8Itd5vc8mbZ/vCs7u2DeaLkbUIY4tk81urcXP+nk=; Content-Language: en-US In-Reply-To: <831qn91qo0.fsf@gnu.org> Received-SPF: pass client-ip=2a01:4f8:121:346::180; envelope-from=mail@daniel-mendler.de; helo=mail.qxqx.de X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-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.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:302859 Archived-At: On 2/1/23 14:06, Eli Zaretskii wrote: >> From: Robert Pluim >> Cc: larsi@gnus.org, mail@daniel-mendler.de, emacs-devel@gnu.org, >> monnier@iro.umontreal.ca >> Date: Wed, 01 Feb 2023 13:52:19 +0100 >> >>>>>>> On Tue, 31 Jan 2023 20:43:09 +0200, Eli Zaretskii said: >> >> Eli> What's wrong with the first method described in the node "Distinguish >> Eli> Interactive" in the ELisp reference? >> >> You mean like this? Itʼs definitely a smaller change. > > Yes, exactly. Thanks. > > Unless anyone else objects, please install this in a day or two. I object. With this change the non-interactive implementation is polluted with an unnecessary INTERACTIVE argument, which would then allow the non-interactive caller to still pass vector arguments. You could as well call the argument ALLOW-VECTOR. If the non-interactive function gets extended at some point with additional arguments how should we proceed then? I also argue that the primary use case of these functions is non-interactive and that should be prioritized. Why can you not just move the whole conversion business into the `interactive' form? This means we cannot use a string as interactive form but we have to implement our own `keymap--read` function which is then used like this: `(interactive (list (keymap--read ...) ...))`. It is not as concise as the string form but would avoid any problems. As better alternative we could also go with Stefan's proposal to allow vectors as arguments in the first place. This would resolve this issue cleanly without any extra code. Daniel