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: "whether the global keymap C-x 4 will be replaced by a command," Date: Sat, 18 Jul 2020 17:00:08 +0000 (UTC) Message-ID: <5e0de57e-e0a2-4188-bf7e-1fa00fc1ec6e@default> References: <83ft9woo68.fsf@gnu.org> <87wo377wxp.fsf_-_@mail.linkov.net> <87wo353f77.fsf@mail.linkov.net> <87o8ofoy9o.fsf@mail.linkov.net> <87sgdog5b5.fsf@iris.silentflame.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="1727"; mail-complaints-to="usenet@ciao.gmane.io" To: Sean Whitton , rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jul 18 19:01:08 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 1jwqCy-0000MU-NV for ged-emacs-devel@m.gmane-mx.org; Sat, 18 Jul 2020 19:01:08 +0200 Original-Received: from localhost ([::1]:44820 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jwqCx-0006vP-Pa for ged-emacs-devel@m.gmane-mx.org; Sat, 18 Jul 2020 13:01:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58240) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jwqCD-0006R0-DF for emacs-devel@gnu.org; Sat, 18 Jul 2020 13:00:21 -0400 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:38224) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jwqCB-0007ap-9x; Sat, 18 Jul 2020 13:00:20 -0400 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 06IGraLX080502; Sat, 18 Jul 2020 17:00:14 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=8N3rCqwhv9lM3g+LxXuXhZT1uRe6FR7pq+XW28JPnlg=; b=a5iaXAPFs1f5P5zI8fWWGeMwLNknIUaosVSVQkIZaH42VzRXXXE1358eS/+JlzxFVssc F2zk7wjq3ZyH6YV4WocvHO0Sn9h0V6WuimBgTw3lf9gUrbnEFDFXSICHJQMAOWG2/4QR hggbbvNYET5e+LDohRFv3zgc+Jj7RD4wANeE/2slbc/AJa+UsdRlufFQrdRGpZBLGgQW 1Civ+LNEdX8zirN0J9NP6wwRe8oqdXil6w0oTLB42Bc33/3uK5YJOT7wOxklzqJgVzlq x0KtjaGVRR9ui1tcLk9PJp8XwQzrlsIMDgOm4I635GbybGNRh9xRkDm2YlexwAESy7Us LA== Original-Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by aserp2120.oracle.com with ESMTP id 32bs1m1eru-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 18 Jul 2020 17:00:14 +0000 Original-Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 06IGw1WA046197; Sat, 18 Jul 2020 17:00:13 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3020.oracle.com with ESMTP id 32c03hb94a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 18 Jul 2020 17:00:13 +0000 Original-Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 06IH09rI002807; Sat, 18 Jul 2020 17:00:12 GMT In-Reply-To: <87sgdog5b5.fsf@iris.silentflame.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.5017.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9686 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 malwarescore=0 mlxscore=0 bulkscore=0 mlxlogscore=999 phishscore=0 adultscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007180130 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9686 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 bulkscore=0 adultscore=0 lowpriorityscore=0 mlxlogscore=999 malwarescore=0 clxscore=1015 spamscore=0 mlxscore=0 impostorscore=0 phishscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007180129 Received-SPF: pass client-ip=141.146.126.78; envelope-from=drew.adams@oracle.com; helo=aserp2120.oracle.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/07/18 12:17:27 X-ACL-Warn: Detected OS = Linux 3.1-3.10 [fuzzy] X-Spam_score_int: -63 X-Spam_score: -6.4 X-Spam_bar: ------ X-Spam_report: (-6.4 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-1, 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=-1, 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:253076 Archived-At: > the feedback I got was that it would be better to > avoid cluttering the function symbol namespace with > lots of -other-window commands. My feedback is that I _want_ separate other-window (and other-frame) commands. Explicit commands. But _not_ in some general, apply-to-all-commands (or all commands that show something in a window or select a window). I want such commands only when and where I want them, and I want them bound to keys only when and where I want such bindings. I don't want something to create such other-* commands willy nilly, automatically. IOW, I want just what we have now: . ability for anyone to explicitly define an other-* command . ability for anyone to bind any same-* or other-* command to any key in any mode or other context. . ability for anyone to _not_ have a given same-* or other-* command be bound in a given mode or context. In Dired, for example, for some actions I want to have _only_ a key that reuses the same window. For other actions I want to have _only_ a key that uses another window - or another frame. And for still other actions I want to have keys for _both_, or all 3, possibilities. To me, it would be a step backward to treat any of this stuff in some one-size-fits-all, blanket way: either by automatically creating other-* commands for everything, or by automatically creating bindings for them. Or by automatically creating the equivalent: providing keys everywhere, for everything, that provide other-* behavior without creating other-* commands. I want only keys that I or some mode or other context has decided are the most useful for that particular context. I have no problem with the supposed "cluttering [of] the function symbol namespace" from the existence of separate other-* commands. (Perhaps that's partly because I use a completion framework that isn't bothered by the existence of two commands `foo' and `foo-other-window' etc.) To me, this "project" of replacing `C-x 4' by a command is an anti-feature. (Same for other prefix keys.) And again, though I've asked several times now, I've seen _no_ description of anything useful that this project aims to provide. So far, it seems only like a thought-to-be-clever solution that's still looking for a problem to solve. If the problem is _really_ only "cluttering [of] the function symbol namespace", then that, to me (just one user) is 100% a non-problem. And IMO it's certainly not worth tossing out the beautiful baby of simple prefix-key bindings to keymaps with the supposedly too-cluttered-namespace bathwater. IMO, that bathwater itself is in fact clean & clear. It's a mountain stream, not dirty suds. Just one opinion.