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 19:20:09 +0100 Message-ID: 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> <137753af-777d-2da3-c111-7e2d414633f1@daniel-mendler.de> <83sffpze9h.fsf@gnu.org> <309dee07-e404-4f84-a839-8b99815376f8@daniel-mendler.de> <83mt5xz42d.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6655"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rpluim@gmail.com, larsi@gnus.org, emacs-devel@gnu.org, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Feb 01 19:20:54 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 1pNHj4-0001bf-66 for ged-emacs-devel@m.gmane-mx.org; Wed, 01 Feb 2023 19:20:54 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pNHiY-0004rd-1P; Wed, 01 Feb 2023 13:20:22 -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 1pNHiU-0004rH-7D for emacs-devel@gnu.org; Wed, 01 Feb 2023 13:20:18 -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 1pNHiR-00047y-Kl; Wed, 01 Feb 2023 13:20:17 -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=hufYwwR7+SDMGoq1ySB2HM1rcfUfc65Ah4KpeSp3Wco=; b=BNMrRsbu+0dLrJsfcl9mSG9Mu8 DVpeytbla5wwyLs+00G66Z9mZ1m6QUEl6s0hJm53BCom2oaQNAGlZ9Ygyx3WTWtPJ2/FoMzpBVEg+ pmELUQiZR8zZntAQeki2aQBEZaLfo74iRDPpFecW76ONqPdbR+t3Ec9qskGF6LX1Qf4M=; Content-Language: en-US In-Reply-To: <83mt5xz42d.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:302871 Archived-At: On 2/1/23 18:30, Eli Zaretskii wrote: >> Of course everything is possible. But that's not my point here. The >> keymap.el API is a newly designed API, so please let's design it in a >> clean way, where we don't have meaningless arguments. > > The advertised API wouldn't change. We don't expect anyone to use the > additional argument in non-interactive invocation. We can use > advertised-calling-convention declaration to hide that argument from > documented interfaces. That's good. If the argument is not advertised then the implementation detail is at least hidden superficially. > I'm also okay with using called-interactively-p, but I thought for > once we should do what we preach. (And whoever wants to circumvent > called-interactively-p can always use call-interactively anyway.) But > if people dislike the method that we ourselves document as the > preferred one, I can live with the second best. I think call-interactively-p would be better for this use case, but that's my opinion versus yours. >> I am not fine with making a mess out of an API which have been >> designed newly from the ground. > > We are not messing anything, see above. These are all accepted, > documented, and recommended techniques. I get it that you don't like > them, but the documentation clearly indicates that your opinions on > this are not shared by the project. Actually, I agree that using an interactive argument is an acceptable approach in some cases. I use this technique myself in some of my projects published on GNU ELPA, so what you write is factually wrong. But if there is a rule or recommended technique, there can also be an exception. I still believe it is better to not leak implementation details as an optional argument in this case, even if it is hidden via the advertised calling convention. Robert mentioned that an additional interactive type K could be introduced. That might be a good long term solution, but requires more intrusive changes which are out of question for emacs-29. Daniel