From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Standardizing more key bindings? Date: Tue, 06 Oct 2020 10:43:24 -0400 Message-ID: References: <8c05eb11-102d-4d94-21ba-b60ceb6d9c43@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36113"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: thibaut.verron@gmail.com, emacs-devel To: Nikolay Kudryavtsev Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Oct 06 16:45:23 2020 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 1kPoDR-0009FX-H7 for ged-emacs-devel@m.gmane-mx.org; Tue, 06 Oct 2020 16:45:21 +0200 Original-Received: from localhost ([::1]:38156 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kPoDQ-0000Qm-JF for ged-emacs-devel@m.gmane-mx.org; Tue, 06 Oct 2020 10:45:20 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60352) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kPoBe-00073h-Ui for emacs-devel@gnu.org; Tue, 06 Oct 2020 10:43:31 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:16208) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kPoBc-0007IQ-M7 for emacs-devel@gnu.org; Tue, 06 Oct 2020 10:43:30 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 1825710023C; Tue, 6 Oct 2020 10:43:27 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 95AC2100071; Tue, 6 Oct 2020 10:43:25 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1601995405; bh=7PGGr6l9tyiHMF/DzX5q+OD4q0hkUPNUS3Nywoo5Beg=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=pxd63cu+BuDZIc7zDx/2gbSFgAumS7BNt+nDCG1OUqaQZrkC3od7wpJhhabYMVol1 u8Ct9ubkn1VgXOMxejWY7UK/a69xv1X0m8ldTBYcXCafX9IcPncxTclyKQAr48ZIhq 02aSkCmDUNoQ97eG7q4RfYFLO0V88cklEkUQi7vs7r3TjGVvDWn5XNcmVKcJ20ci7r Il2xbwTDqgH10/A8eEp+BQFpv3eTZCh1PxjU8E4lNtTJqi8Fj7wj02VD2EKEZGTs0F KlCNZLXPJar3GYmR68q08JP4+KPLPR/2QZb1ftervFpc2ttZyYLP9xPmXBQIibGQv2 8lQYHjej2SXlA== Original-Received: from alfajor (unknown [157.52.9.240]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 6C966120028; Tue, 6 Oct 2020 10:43:25 -0400 (EDT) In-Reply-To: <8c05eb11-102d-4d94-21ba-b60ceb6d9c43@gmail.com> (Nikolay Kudryavtsev's message of "Tue, 6 Oct 2020 17:24:14 +0300") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/06 09:08:42 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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.23 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" Xref: news.gmane.io gmane.emacs.devel:257167 Archived-At: > So one decent example I have is minibuffer completion. Lets say I'm using > ErgoEmacs and it expects previous element to work on F11 and next element on > F12. But there are multiple minibuffer completion packages, like Ivy, > Icicles, Helm and ErgoEmacs developers have to currently try to provide > concrete bindings for whatever they choose to support. The problem with it is that all of those completion packages provide a slightly different set of commands. So while the "next element" and "previous element" command can easily be handled such that the choice of key is handled elsewhere, you're still stuck with the choice of key for the commands specific to Helm (say), unless your protocol covers "a superset of all the completion packages". If it's not a superset, then the few missing commands will end up sticking out like a sore thumb (or even conflict with some other keybinding). So, I think the "keytheme" packages should be able to do more than give explicit bindings to a particular set of (concrete or abstract) commands. They should also be able to describe their style in a more "intensional" way, which would be used to *compute* the key to use for a new command based on some suggestion from the command's package. Stefan