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.bugs Subject: bug#61184: 29.0.60; keymap-local-set and keymap-global-set became less strict Date: Mon, 30 Jan 2023 23:03:03 +0100 Message-ID: <9fd41d2c-4d75-271b-d3a8-8ca8d5e6229a@daniel-mendler.de> References: <5876987d-2479-f512-5767-218c8c16a909@daniel-mendler.de> <2b0f16c2-2890-b1a6-8d10-3569caefbc1d@daniel-mendler.de> 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="28370"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, 61184@debbugs.gnu.org, rpluim@gmail.com To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jan 30 23:04:29 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1pMcGK-00078y-R8 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 30 Jan 2023 23:04:28 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pMcG2-0007kc-4U; Mon, 30 Jan 2023 17:04:10 -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 1pMcFu-0007d1-7N for bug-gnu-emacs@gnu.org; Mon, 30 Jan 2023 17:04:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pMcFt-0000DU-UY for bug-gnu-emacs@gnu.org; Mon, 30 Jan 2023 17:04:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pMcFt-00005O-Pt for bug-gnu-emacs@gnu.org; Mon, 30 Jan 2023 17:04:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Mendler Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 30 Jan 2023 22:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61184 X-GNU-PR-Package: emacs X-Debbugs-Original-Cc: Lars Ingebrigtsen , bug-gnu-emacs@gnu.org, Robert Pluim Original-Received: via spool by submit@debbugs.gnu.org id=B.167511619632720 (code B ref -1); Mon, 30 Jan 2023 22:04:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 30 Jan 2023 22:03:16 +0000 Original-Received: from localhost ([127.0.0.1]:50799 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pMcFA-0008Vg-9C for submit@debbugs.gnu.org; Mon, 30 Jan 2023 17:03:16 -0500 Original-Received: from lists.gnu.org ([209.51.188.17]:33146) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pMcF8-0008VY-Hm for submit@debbugs.gnu.org; Mon, 30 Jan 2023 17:03:15 -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 1pMcF6-0006dR-11 for bug-gnu-emacs@gnu.org; Mon, 30 Jan 2023 17:03:14 -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 1pMcF3-0008U0-KP for bug-gnu-emacs@gnu.org; Mon, 30 Jan 2023 17:03:11 -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=WOE5EE4g2UmPVXYfK+AdBbC0crbRdPRTVTWv4EJBBas=; b=otuCXsQGz1B2tq6PU597eSFdFC QHe8XbFbUJrHJ8WrCh43hve9lvmu41x+cVPewTDxywmkCgTLNBe3RzTyF+08JZLZZ51vULmuGHqJf 14bmfnxLmVbJIUnZpX++4jLJw1PJQTWlxjepel3YnUAEPPYWo3L5HTvia6pVQGgBRkl8=; Content-Language: en-US In-Reply-To: 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: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:254487 Archived-At: On 1/30/23 22:45, Stefan Monnier wrote: >> I think what Lars had in mind with a strict string-only API for >> keymap.el, since this creates a consistent picture for keymap >> definitions. I agree that internally the vectors are not going away and >> that is okay, but this does not prohibit creating the more strict >> superficial string only API. > > It's still a PITA when you have a vector and you need to pass it to > a function which happens to be usually receiving its data from end-users > and hence passes its inputs through `key-parse`. I tend to agree. Also I recently had to write a few times (keymap-set map " " #'long) where I would have preferred to write (keymap-set map [remap not] #'long). The same with `defvar-keymap' which also needs this long remap syntax. > Accepting vectors in `key-parse` doesn't prevent the construction of > a consistent picture where end users only need to know about > KBD-style strings. Yes, but I am no fan of "hiding the truth" in the documentation. It would not be bad to accept both the strict string syntax and vectors, and also document that. It would still be consistent, maybe even more so when considering the whole Emacs where many internal keymap and event functions operate on vectors. I hope it is not too late to fix the API for Emacs 29 such that it becomes consistent. When the API is officially released it is harder to change it. All functions should only accept the strict string syntax as defined by key-valid-p, including the key-parse function. As Stefan argues, the functions could also accept vectors, but then please - all of them. I would not mind that and may prefer it in some cases like the remapping or when you already have another vector anyway. On the other ahnd I also see the merits of the more restricted string only API, which would be simpler to explain and one would not have to hide the truth in the doc string. For internal uses with vectors there are still define-key and the other APIs. Daniel