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 21:22:21 +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="24383"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , rpluim@gmail.com, larsi@gnus.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Feb 01 21:23:17 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 1pNJdU-00065W-D7 for ged-emacs-devel@m.gmane-mx.org; Wed, 01 Feb 2023 21:23:16 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pNJco-0007m3-O8; Wed, 01 Feb 2023 15:22:34 -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 1pNJck-0007lj-Ul for emacs-devel@gnu.org; Wed, 01 Feb 2023 15:22:31 -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 1pNJch-0002Z4-Ac; Wed, 01 Feb 2023 15:22:29 -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=lAeymhC368tMxybJrj4h+XIpVT5qIwe1AoPOLNqTvi0=; b=JyA5cLH9ffoKOduKRYxTjYhgVj 8jkZmvI3fJvtnLSHS7NhyH6bkqNyG+RqTn+CqMzIkLcVJRRK5ZpThcDhVSmpHgEDcfQaznMN9t2eF 7GXh9O14fxmzbdOalsd963FxzE2ayVl3DKnFii4PMddoDHmUiGq2NV26NKk2U5p9aPR4=; 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: 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:302877 Archived-At: On 2/1/23 19:54, Stefan Monnier wrote: >> I think call-interactively-p would be better for this use case, but >> that's my opinion versus yours. > > Have you ever looked at the implementation of `called-interactively-p`? I guess there is no doubt that we all agree that the implementation is not great. But I would not consider it prohibitively bad, such that it should never ever be used in new code. If that is the case why is the function not officially deprecated? To be clear, I was aware of the recommendation to avoid `called-interactively-p' and iirc I have not used it in any of my packages. It is a kludge to use it, but using "hidden arguments" and "advertised calling convention" seems as much a kludge in my eyes. Is it commonly agreed upon that advertised calling conventions are the lesser evil? I've usually understood advertised calling convention as a means for deprecation - did I misunderstand that? I wonder if `called-interactively-p' would lead to actual problems in this particular use case? The problem with the hidden INTERACTIVE (or ALLOW-VECTOR) argument is that it is still somewhat exposed to non-interactive callers. For example, in the context of the Compat library, should this argument be made available, since non-interactive callers may want to use it? What if callers start to use it if they want to pass vector arguments? An example where INTERACTIVE arguments seems more justified to me are the `completion-at-point-functions' provided by my Cape package. The Capf `cape-line', which also happens to be a command, completes full lines in a buffer. If called interactively or with a non-nil interactive argument, it will use `completion-in-region'. The nice property is that the equivalence `(call-interactively #'cape-line) == (cape-line t)` holds. To come back to `keymap-local-set' - the good thing is that we can avoid both kludges, advertised calling conventions and `call-interactively-p'. All we have to do is move the key reading entirely to the interactive form, which also seems to be semantically most correct. If I would rate the possible solutions: 1. Just allow vector arguments for all the functions. Simplest solution, least amount of code. 2. Use `(interactive (list (keymap--read-key) ...))`. Unfortunately this solution lead to technical difficulties in the `keymap--read-key' function. 3. Use the `call-interactively-p' kludge. 4. Use the hidden INTERACTIVE argument kludge. Unfortunately none of the solutions 1 to 3 seems to be good enough. Daniel