From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "John S. Yates, Jr." Newsgroups: gmane.emacs.devel Subject: Re: Qs on key-description, substitute-command-keys Date: Sat, 15 Oct 2005 14:00:09 -0400 Message-ID: References: <878xwvuhwu.fsf-monnier+emacs@gnu.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1129398647 13219 80.91.229.2 (15 Oct 2005 17:50:47 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 15 Oct 2005 17:50:47 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 15 19:50:44 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EQqAg-0007q1-Oe for ged-emacs-devel@m.gmane.org; Sat, 15 Oct 2005 19:50:15 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EQqAg-00074c-7y for ged-emacs-devel@m.gmane.org; Sat, 15 Oct 2005 13:50:14 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EQqAO-00074X-TX for emacs-devel@gnu.org; Sat, 15 Oct 2005 13:49:56 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EQqAN-00074L-A2 for emacs-devel@gnu.org; Sat, 15 Oct 2005 13:49:56 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EQqAN-00074I-4h for emacs-devel@gnu.org; Sat, 15 Oct 2005 13:49:55 -0400 Original-Received: from [63.240.76.49] (helo=sccrmhc14.comcast.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EQqAN-0007Lc-CM for emacs-devel@gnu.org; Sat, 15 Oct 2005 13:49:55 -0400 Original-Received: from mail.yates-sheets.org ([24.218.47.3]) by comcast.net (sccrmhc14) with SMTP id <2005101517494801400n7i2ke>; Sat, 15 Oct 2005 17:49:52 +0000 Original-Received: from 10.1.1.12 ([10.1.1.12]) by mail.yates-sheets.org (WinRoute Pro 4.2.5) with SMTP; Sat, 15 Oct 2005 14:00:16 -0400 Original-To: Emacs-Devel In-Reply-To: <878xwvuhwu.fsf-monnier+emacs@gnu.org> X-Mailer: Forte Agent 3.0/32.763 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:44088 Archived-At: On Sat, 15 Oct 2005 07:54:14 -0400, Stefan Monnier wrote: > There is no way to get this kind of control. `substitute-command-keys'= has > some rules such as "prefer a binding using plain ascii keys" (so it'll > prefer C-x < over C-next, based on the principle that not all terminals= have > a `next' key and even fewer have a way to generate a C-next event) and > "prefer a shorter binding". While I can understand the impulse behind this heuristic, it ultimately seems paternalistic ("we need to prepare you for the great variety of terminals that you may encounter"). A better approach might be a set of configurable rules that would lead to a considered choice.=20 1) Emacs can usually query the environment to determine the nature of the keyboard in use. With this information it can exclude bindings that = would be impossible to produce. In the same vein, if the menubar is not = displayed there is again no point in suggesting menu bindings. 2) There should be a set of rules. I imagine an ordered set of = predicates. After applying the hard filtering described above, if more than one = binding survives, develop a per-binding preference strings as follows: apply each predicate in order; encode each failed predicate as '0', and each = successful predicate as '1'. Compare the strings lexically. The lexically lowest = string will correspond to the most desirable binding. (With a limit on the = number of rules an analogous scheme could be implement using bit strings encoded= as integers.) My hope is that after describing my preferences as a set of rules, emacs would oblige me by suggesting bindings compatible with my idiosyncrasies. In particular I would like this to work for new packages that I have not used before, let alone customized in any fashion. /john a users is likely to find=20 /john