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: Thu, 2 Feb 2023 10:29:56 +0100 Message-ID: <43deaa5c-2f55-fe12-7447-be345d55420b@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> <137753af-777d-2da3-c111-7e2d414633f1@daniel-mendler.de> <83sffpze9h.fsf@gnu.org> <309dee07-e404-4f84-a839-8b99815376f8@daniel-mendler.de> <83mt5xz42d.fsf@gnu.org> <21d9dd07-22f6-03be-1c8b-5d7e4fd1ff80@daniel-mendler.de> <831qn8zh84.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="32810"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, rpluim@gmail.com, larsi@gnus.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Feb 02 10:30:57 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 1pNVvk-0008JY-Hc for ged-emacs-devel@m.gmane-mx.org; Thu, 02 Feb 2023 10:30:56 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pNVv2-00010z-GY; Thu, 02 Feb 2023 04:30:12 -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 1pNVux-00010X-PE for emacs-devel@gnu.org; Thu, 02 Feb 2023 04:30:08 -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 1pNVuv-0000MU-7H; Thu, 02 Feb 2023 04:30:07 -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=uboPmkS4UZ+E7qWLx5PmPZFRGP5aqlLAsm5acfPIcw0=; b=Gew6RQSE22fEl1n+cLRw2L2Hy7 Oqdv2fFp/n2/+rxRcQ7HOLr++YYiM+ZtZ5+03AhwJqeEd1B6iHuQoC0zbJTI10/5Gj9RPl+EEa+Ey L3tkNbLKYwG1vU1R/Xq6tzDG+g3zIsz67wfIjsnu+2I5hJ/ULpil1n92U1ZHDwPc7YeY=; Content-Language: en-US In-Reply-To: <831qn8zh84.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:302896 Archived-At: On 2/2/23 07:58, Eli Zaretskii wrote: >>> Emacs is not in the business of imposing The Right Way, instead we >>> prefer to encourage it while still allowing people to shoot themselves >>> in the foot in all kinds of fun ways. >> >> Tell that to Eli, who seems to be in the business of preaching The Right >> Way and also following it. > > But preaching is very different from imposing. And I think "do as I > say, not as I do" is not a great stance for us (although we sometimes > do it). You preach and impose it on the new API. But it is okay. >> But that's beside the point - keymap.el is a newly introduced library >> with a newly designed API. I would expect that such a library can be >> implemented according to the best practices without any kludges - >> without `call-interactively-p' and without advertised calling >> conventions. That this does not seem to be possible, leaves me >> unsatisfied. Well, it would actually be possible, we just have to do it >> differently - either allowing vectors as arguments or by using a >> different interactive form calling `keymap--read-key`. But these better >> solutions were rejected for other reasons. > > We could go for a different design if we had more time. These > functions were introduced just 2.5 months ago, and the problems with > them were only brought to our attention very recently. We don't have > enough time to switch to using other APIs in the interactive form, as > we had bitter experience with doing that in similar cases (subtle bugs > and behavior changes that took many moons to uncover and even longer > to fix). It's too bad no one tried these new commands earlier and > reported the problems back then, but that's water under the bridge. > So we don't have the luxury of going for the ideal design. We must > choose one of the safe solutions that will not delay the pretest nor > endanger its quick success and the following release. I prefer the > additional argument method, and it sounds like so does Stefan. I agree that we should be careful for emacs-29. I think you convinced me that the additional (non-advertised) argument isn't worse than `call-interactively-p'. I would still prefer a solution without either of those kludges (or maybe even just allowing vector arguments to avoid the complications), but I've repeated that often enough. Maybe when the API is overhauled the next time. Thanks for the consideration and thanks for addressing this issue in the first place. Daniel