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 22:06:01 +0100 Message-ID: <2b0f16c2-2890-b1a6-8d10-3569caefbc1d@daniel-mendler.de> References: <5876987d-2479-f512-5767-218c8c16a909@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="20535"; 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 22:07:59 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 1pMbNf-00052k-6n for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 30 Jan 2023 22:07:59 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pMbNZ-0001zO-BZ; Mon, 30 Jan 2023 16:07:53 -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 1pMbMx-0001QU-4s for bug-gnu-emacs@gnu.org; Mon, 30 Jan 2023 16:07:19 -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 1pMbMk-0006bL-Ms for bug-gnu-emacs@gnu.org; Mon, 30 Jan 2023 16:07:14 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pMbMk-0006uv-H8 for bug-gnu-emacs@gnu.org; Mon, 30 Jan 2023 16:07:02 -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 21:07:02 +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.167511276926517 (code B ref -1); Mon, 30 Jan 2023 21:07:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 30 Jan 2023 21:06:09 +0000 Original-Received: from localhost ([127.0.0.1]:50719 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pMbLs-0006td-W9 for submit@debbugs.gnu.org; Mon, 30 Jan 2023 16:06:09 -0500 Original-Received: from lists.gnu.org ([209.51.188.17]:35700) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pMbLr-0006tV-57 for submit@debbugs.gnu.org; Mon, 30 Jan 2023 16:06:07 -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 1pMbLq-00077L-PS for bug-gnu-emacs@gnu.org; Mon, 30 Jan 2023 16:06:06 -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 1pMbLp-0006Vu-7I for bug-gnu-emacs@gnu.org; Mon, 30 Jan 2023 16:06:06 -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=9xstT1JHUWzjxzVewiLLSG/eReW4H3urXRNi5XaSzq4=; b=DGyJiuVrCrOwmEyI2avRsupU6R TZSb4LFsRpi0S/Pu2ElITVAUQtRh7EhHpjF7jhu5rWL9B9JASbiIXpc8LGfsuLbxHm51eva66y98n /ltBm5s+JmJh3hvsnHdHRu8syRhBGA+UfFuUTWanU+2u7n6f4qKgYozuIytQjdJPACJ8=; 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:254482 Archived-At: On 1/30/23 22:00, Stefan Monnier wrote: > I don't see any use for the vector->string conversion to happen in the > interactive spec: I think the most important use cases for accepting > vectors is when these come directly from Lisp, in which case having to > convert them back to the KBD syntax (only to hope `key-parse` will > correctly undo the damage) is just a waste and a hurdle. > Obviously, I disagree: the vector format is not going anywhere, so it > makes a lot sense to accept it, even though I fully agree that guidance > should never suggest the use of the vector format. Stefan, I know that you disagree, see the other thread. I am not the one to debate this with. Please discuss this with Lars, who introduced the API and intended it to be as strict as it was. Now the API gets relaxed through the backdoor because of the broken interactive use. This is why I am objecting. All I want is that the keymap.el API overall is consistent - currently it is not. The keymap-local/global-set made parts of the API accept vectors, key-parse accepts invalid strings and the rest seems to only accept strictly conforming key strings. 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. Daniel