From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: [External] : Re: Concern about new binding. Date: Fri, 5 Feb 2021 18:22:19 +0000 Message-ID: References: <87zh0mmr54.fsf@gmail.com> <87y2g5smya.fsf@gmail.com> <4FF55FBF-573D-4A70-B3FC-682CA25B7ECB@gnu.org> <83lfc53whk.fsf@gnu.org> <20210203180142.seu6o3i6u7jhkyrh@Ergus> <83eehx3to5.fsf@gnu.org> <20210203221628.xgvvxjvh56gyswba@Ergus> <20210204070033.pm4ido4hq7a6twif@Ergus> <83sg6brhyg.fsf@gnu.org> <87a6sjpyqs.fsf@gnus.org> <838s83ra3q.fsf@gnu.org> <87mtwjocn7.fsf@gnus.org> <87wnvnmqhx.fsf@gnus.org> <87o8gz40ex.fsf@red-bean.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4678"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lars Ingebrigtsen , Gregory Heytings , "emacs-devel@gnu.org" To: Karl Fogel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Feb 05 19:53:34 2021 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 1l86EX-000171-Mo for ged-emacs-devel@m.gmane-mx.org; Fri, 05 Feb 2021 19:53:33 +0100 Original-Received: from localhost ([::1]:33954 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l86EW-0002vm-NF for ged-emacs-devel@m.gmane-mx.org; Fri, 05 Feb 2021 13:53:32 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34754) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l85kS-0005Uy-F1 for emacs-devel@gnu.org; Fri, 05 Feb 2021 13:22:28 -0500 Original-Received: from userp2130.oracle.com ([156.151.31.86]:43306) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l85kP-0004YZ-Bd for emacs-devel@gnu.org; Fri, 05 Feb 2021 13:22:27 -0500 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 115IKOP0191697; Fri, 5 Feb 2021 18:22:22 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=corp-2020-01-29; bh=RN5X1yPRBcGMOEgr9p0/m2VLAPRccueNnbrfOejaxdI=; b=TJYK6r6q1wDqB5NJKKgVyCvK3VtNKzFjh+kyWqoHTAN9TJ02HbkSCmwXKh/KMh5hDxGv Gv6sgVzpyimMNko0C7jwaaAymmLvZx5Fbf0kaB9OzXSVZ2TyFJFIch+/sB0nx7yk/OyT ytv5cs/20UpxJSMWRNq+2NcDnxZ5+cI8cQhiBr/hl/U8t4sUlBwjNvVIuHVGxf6Fc2QU ZJgBMJqmmjWbN/eHqGboD+Vwsg+wTIhg+/cwpFMYwgD0KCOzXrLgkkHFw/c6cLug7htf +gOz5m8ZIAeodCleAiYWLXy/MGVxsm07VTLhn1M/435PQ/nWOOihA3oChpu99Lp0BfE9 Pg== Original-Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2130.oracle.com with ESMTP id 36cxvrdev9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 05 Feb 2021 18:22:21 +0000 Original-Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 115IEjbt168361; Fri, 5 Feb 2021 18:22:21 GMT Original-Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2174.outbound.protection.outlook.com [104.47.59.174]) by userp3030.oracle.com with ESMTP id 36dhd3bjhn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 05 Feb 2021 18:22:21 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DXRcessEpKWHH7zgbtt4aOTC/xTYkOPug7PYT7pROmq/M/CYBpw4UdZKtC0g9SiI4XrTo0thoUVcv+wb6gF7eAzN7KXd68R4ID+CP3MhFePxo7exWM7M47g0nnib/2ieiLBVaWI/JLl+7CC/UEOKdYDHrg4A6wNGSkQZkBd3O2fuNqn/MqM/cdrz8GASSztxDRPJZh/8+zO/nXhYkS/ePQLnU+koL2VZLoNeCNb1PA1NLZGEbdWce9dwkeYyO4agBPuKpMwdpJjLbqhrqu4baQpUJoFPd2UGVU3UjmQ06mNMsujdh7SSYdpXXs8n7J41aGuzvrDxTKtJVJgGFsEG9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RN5X1yPRBcGMOEgr9p0/m2VLAPRccueNnbrfOejaxdI=; b=h6tWwxnTSmuV/hi2rtmYxFQ7p7uWiyOu5S0t5zA0JhW5eMenueGoaU3bVtmpaXgU3/eFfrWCcHirWbibqgMbNz4lQ94YO07wwFEJn77kVGiKdFDmPhazybx1EmUFlo6DgpKkeG3nZEtEd1uQUI3M/1HOxQckb/gptqH7nYxwUtivguo2iUw5HwVghFxW/P/JTwVe3ZP4fBuMbW35p3Y8gnrqNeyNTYM4HfRxDUOlhNiAAFYCKk7eRfdO69GPEtEC+Iw/33pfzdVwFNVTrEFGZp4UsQNiiFVa8nL6Kex6fAyxqPRk3DdbYh6sIdsPWge/SwO83LcFkdKQdqNQUoMlUA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RN5X1yPRBcGMOEgr9p0/m2VLAPRccueNnbrfOejaxdI=; b=aPuxm/MUye9MDIWVAXb43qmGBoyBiKwKdvbc3KF1RjUVtcxk+CwYWMtZ+a57Pu0ts5vXjk+15/qOcHLb7gWWzIFHPcBG43A5lj5/rT0RHiwWa4F2j4Bn3S4QWLS97vLE3CyUXDZZ/ER9h2YJOQvNZeumKbQh53aOQav/rnh6NJc= Original-Received: from SA2PR10MB4474.namprd10.prod.outlook.com (2603:10b6:806:11b::15) by SN6PR10MB2432.namprd10.prod.outlook.com (2603:10b6:805:46::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3825.17; Fri, 5 Feb 2021 18:22:19 +0000 Original-Received: from SA2PR10MB4474.namprd10.prod.outlook.com ([fe80::dc4d:9cd0:2010:daa2]) by SA2PR10MB4474.namprd10.prod.outlook.com ([fe80::dc4d:9cd0:2010:daa2%7]) with mapi id 15.20.3825.024; Fri, 5 Feb 2021 18:22:19 +0000 Thread-Topic: [External] : Re: Concern about new binding. Thread-Index: AQHW+3VL05sLP8G0VkuKLJFk4nC0r6pJv/PA In-Reply-To: <87o8gz40ex.fsf@red-bean.com> Accept-Language: en-US Content-Language: en-US authentication-results: red-bean.com; dkim=none (message not signed) header.d=none;red-bean.com; dmarc=none action=none header.from=oracle.com; x-originating-ip: [73.170.83.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c3eaf42d-6000-4969-3a03-08d8ca02f96e x-ms-traffictypediagnostic: SN6PR10MB2432: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: mwZrHIUlW4srjMMpeop7ARHCyigmuhlPtZedbn4JqqUNwc5ZNralDzpLv4te3otex1pw4pYaRGwx+j5Y0AdWTAj6IgkxYCbtax+CjW56jT8wQX0xSddJa4OOykWoPAHyR1EyMHoTu1Al0Xj73du8oEBt8MBpJOnYWZc1u5M+ySPMRLHFvY8v7DIHv5z3srm+cO4Nv5kY+7p8e6kyVMFV8HGoR9zHa6jJXaHnm77s2xTkxdIbPyyYdxLeRpwJoalI0M7bG5n+VRc87BrImn1+sKBXluND/c9lboqXj/+dWmU90tBK36Sh+SSe78XGx+SvStbLayY0u2ouhjjDuVM1OV+zJeVrPUjiY7g/PkJ0LaJ+pWPBitL7Gasu+3dWoZ4OaRbcnCSwXvJXaGUDlen0Rf2/7BxTVVpACs8oXj5bo8gJqtZEtjfFdpo1f6eYKwi9+ISgE0jQAWSUd1K9qSvuDUVchJQbuI7qUMa2B4gTN26DexttXYsEYfOXXsd8ja7cImx1JXPOILdOE67B718y9w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA2PR10MB4474.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(366004)(39860400002)(346002)(396003)(376002)(33656002)(71200400001)(6506007)(7696005)(8676002)(4326008)(54906003)(316002)(186003)(26005)(44832011)(52536014)(8936002)(6916009)(66446008)(64756008)(76116006)(66556008)(66476007)(66946007)(86362001)(5660300002)(9686003)(478600001)(2906002)(83380400001)(55016002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?kj/8baFzPGFUcmIx3p86+OTlHikso9gpMIJkgIF72twL6u4F139WWz3y3J1R?= =?us-ascii?Q?DYW50YQjUKDIAn4tPaESQNYX3AqLq1egGm6CBzo8kog73Pz+80Xc4VfY9W/m?= =?us-ascii?Q?4tLeu0Ra08qIXwd+RzB7/wgeUwOLN8pciO6gRHd6aLZMSLeCch7XqGg2hhlL?= =?us-ascii?Q?fiza2JR73SIQxzQMUcgymChOiCCO4kAUYK4EDHjLQgwdOZF7OoXGurvPRvbB?= =?us-ascii?Q?NGv9s/BelbzkmdlaRkUYsH1EbtENszquAlz5zpQ6Kvp3wzuc7nJ7UaEyVdKa?= =?us-ascii?Q?UJXchKh2AtjwXNCQ/nnpv64X0iKlbO8TX/6+cN6HF245oKiE6Dyetl/5ZWdW?= =?us-ascii?Q?byV0B+rXVRg2bnEdiLYJFHoZBDKSffyRaG+IYGlaHdwK/RPW/7d09q/3uEI9?= =?us-ascii?Q?dPnORouG06r4H3RRXDvc1fIgWuGlB9i0g5FKMwf2+X+kWc8DzoEVuQ9KOEqn?= =?us-ascii?Q?2zsRhjb669NLG9+VtrOjYg0ssaBV1yG4icQWZlxuTaxG/ZApvBqnCWjf748T?= =?us-ascii?Q?2ISF7sOVR5GUFoE9rNDjkDWvk6i+qxMAau6/z+bLjWBRmemyQ+RJOSbucrlO?= =?us-ascii?Q?cgFXHhIEoF8C4MeVoatGNKk38PBZfx7GMud5hPP+RHgt2V1z6pkCGFy4FF7n?= =?us-ascii?Q?Q2b1 x-ms-exchange-transport-forked: True X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA2PR10MB4474.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c3eaf42d-6000-4969-3a03-08d8ca02f96e X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2021 18:22:19.5764 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 0pjAczaVb1e9cTMnSrezQT2HaSOvNQpg22h17JxuY5J3hcRPO+ISPwsHK7TlozJfmwaX2954RZJ9J/tTu4qx6A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR10MB2432 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9885 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 mlxlogscore=947 phishscore=0 spamscore=0 suspectscore=0 malwarescore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2102050114 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9885 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 mlxlogscore=999 mlxscore=0 priorityscore=1501 spamscore=0 impostorscore=0 clxscore=1011 suspectscore=0 lowpriorityscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2102050114 Received-SPF: pass client-ip=156.151.31.86; envelope-from=drew.adams@oracle.com; helo=userp2130.oracle.com X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, 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.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:263997 Archived-At: > Drew is making a good point here (I realize he sounds a bit > annoyed, but I can sympathize). His proposal make sense -- or at > any rate, there's a good proposal easily derived from what he's > saying. >=20 > If Emacs were to declare that from this point forward it will > leave all currently-unbound `C-x LETTER' unbound, and *recommend* > that packages not bind them by default either, then we'd have a > few more very convenient keybindings left over for users. >=20 > A package could still suggest `C-x SOME-SPECIFIC-LETTER' as a > binding for some entry point in the package, and even provide > convenience mechanisms to cause that binding to happen. >=20 > We can't easil survey users about their bindings, but anecdotally > it seem like a lot of people -- not only Drew -- have been using > those last few remaining slots under `C-x' for their own favorite > things. (The fact that some packages also use that space is a > clue that people consider that space to be desirable real estate > in the mental keymap universe.) >=20 > This isn't about Magit per se -- it's bigger than Magit. However, > this proposal would make it somewhat more okay for Magit to > continue binding `C-x g' by default too. While Magit wouldn't be > following the new recommendation either, at least Magit would not > have to worry about clobbering some existing binding. Given that > Magit is so popular and so many people are accustomed to that > binding already, this is still a decent outcome in the specific > case of Magit anyway. (The fact that Magit also binds `C-x M-g' > by default is a separate headache, but that doesn't have to be > resolved for this proposal to be considered.) >=20 > These days, when we decide to make a new global function binding > in default Emacs, it's hard to imagine how the new binding could > be *so* important that it must take over one of the existing free > convenient slots and yet somehow not be important enough for us to > just replace some other less important binding (thus leaving the > free space free). >=20 > I'm not saying that scenario couldn't happen, but it's going to be > rare. It's certainly not happening in the case of > `revert-buffer'. I mean, let's ask ourselves: if having > `revert-buffer' on a convenient key isn't important enough to > replace some other little-used binding, how on earth can it be > important enough to replace one of the free bindings? After all, > those free bindings aren't *actually* free -- users are using them > for lots of things of their own choosing! >=20 > Emacs has always rewarded users who learn to customize their > keybindings. Let's make it possible for that reward to be as > large as possible by guaranteeing them some conveniently free > slots for their favorite functions and keymap prefixes. >=20 > The `C-c LETTER' space is great, but it's only 26 letters. I used > them up long ago, and I'm sure I'm not alone. Having 4 or 5 more > letters under `C-x' would be a significant boost. I agree with all that Karl wrote, and the way he expressed it. I would, however, emphasize a distinction between (1) users and 3rd-party libraries and (2) the code of vanilla Emacs. While I think it's positive for 3rd-party libraries to only _suggest_ such bindings, I don't think that needs to, or should be, part of the convention. I think, instead, that the "rule" should just be that vanilla Emacs should (modulo important reasons) not grab any more such key bindings. The problem, at least so far, and I think in general, is not really competition for scarce keys among 3rd party libraries. The problem is vanilla Emacs using up the space of possible key bindings for its default keys. Some library, even a very popular one such as Magit, binding some `C-x ' key is not a big problem. Use of that library is optional. When vanilla Emacs claims a key for a (default) binding, that act has a lot more clout. ___ I'd also like to see such a moratorium imposed for _all_ additional keys, not just `C-x ' prefix keys, and not just other multiple-key prefix keys. IOW, I'd like to see vanilla Emacs try harder not to bind new keys by default. Keys are just too scarce now, and users and libraries need keys too. ___ Finally, let me offer another controversial suggestion, which could offer help in another direction. If we were to reexamine Emacs default key bindings in general, at first ignoring existing habits etc. (but later taking them into account), we could, I think, find some existing default keys that could helpfully be repurposed for something more useful. In particular, we could take some keys that are repeating (just hold down the key to repeat the command) but that are currently wasted on non-repeating commands, and either reassign those keys or change their commands to in fact be repeating. Even more useful/important would be to take some such keys, which could usefully be used as prefix keys, and make them such. Consolidate multiple commands, which today waste multiple keys, onto a given prefix key. Even just a little such reconsidering/refactoring work could provide considerable benefit. Of course, yes, the discussion might involve considerable churn. It would maybe help to start with concrete suggestion of keys that some think might be recuperated because they're currently a bit "wasted". One that comes to my mind, but I offer it only as an example, not because I care much to get rid of its binding in particular, is `C-o'. It's repeatable, but is it very useful? (And it doesn't make use of a negative prefix arg.) There are also keys that fit well into our mnemonic scheme, but that maybe have outlived their usefulness - as default bindings. I'm thinking of `C-t', for example. Yes, I do use `C-t', and it can be handy (and yes, you can repeat it, to transport a char forward incrementally - but not backward). But hey, it's a wonderful key, and frankly, isn't it a bit wasted bound to `transpose-chars'? Imagine it as a prefix key, or used repetitively for something more useful than transposing chars. Again, I don't care about `C-o' or `C-t'. I mention those just to give an idea. There are, I think, keys currently bound by default that could be put to better use. A refactoring of Emacs default key bindings could free up some key "space". Yes, at the cost of some finger memory and habit. And yes, we might have trouble finding consensus. And yes, discussion could range too wide and lead nowhere. But it could also be a good thing to try.