From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings Newsgroups: gmane.emacs.devel Subject: Re: [External] : Re: Concern about new binding. Date: Fri, 12 Feb 2021 16:56:28 +0000 Message-ID: <329d68a5ed58df62b603@heytings.org> References: <87zh0mmr54.fsf@gmail.com> <20210204070033.pm4ido4hq7a6twif@Ergus> <83sg6brhyg.fsf@gnu.org> <5588fb25805d486be704@heytings.org> <5588fb2580d7e46863dd@heytings.org> <5588fb2580f248753c30@heytings.org> <5588fb25800032b1a06a@heytings.org> <993b9ce74de32c5450c3@heytings.org> <329d68a5ed872ee02e63@heytings.org> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4824"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: "Alfred M. Szmidt" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Feb 12 17:57:50 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 1lAblN-0001Ac-Q8 for ged-emacs-devel@m.gmane-mx.org; Fri, 12 Feb 2021 17:57:49 +0100 Original-Received: from localhost ([::1]:34756 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lAblM-0008Uq-RC for ged-emacs-devel@m.gmane-mx.org; Fri, 12 Feb 2021 11:57:48 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39870) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lAbkA-0007zi-3X for emacs-devel@gnu.org; Fri, 12 Feb 2021 11:56:34 -0500 Original-Received: from heytings.org ([95.142.160.155]:48382) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lAbk7-0003s1-WD; Fri, 12 Feb 2021 11:56:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1613148989; bh=IvieECaxkEpv32jGdqVjJjA6SWhtsGIblbtvvnRD72g=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=myubC9NF04RBtqD8MsOZMu9v42oa0D7wMrGAJ7mIpp8GjSYuEIejEgjQDXfhtQPA9 pr38XAqarQnWi4a4of7OZsHHnQInLTYXcPX9MSBGXaRUucKTPcBzSFAEdIoW9e0GhQ PpmRg4jfioj5E4dSJ0iL/NJ/+KLjFjQidIuLe3HYXkU3icYlYUab3hLf6hDVyw4Uyx YoYrmv96YUxJjCQsqEJW6YApyPVHOxI8UGQZRe1DAuswKFhOSdfeldYZYE01368ulS wYQ8AlZLosc4+uRmw/Kg28PWY1gtWrM7Hek3+U70EML/1Bfb16g5DVF2X/qh/2LDEy +smgniBXDizTQ== In-Reply-To: Received-SPF: pass client-ip=95.142.160.155; envelope-from=gregory@heytings.org; helo=heytings.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, 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:264528 Archived-At: >>> Most (All?) keyboards today have a Super key -- why not allocate that >>> or parts of it to global third-party packages? >> >> Because the super modifier cannot be used in a terminal or console? > > That is simply not true. > That's what I thought until today, but indeed I may be wrong. Could you please explain how it is possible to use the super modifier in a console? >>> This solves moving things around, and constantly breaking things for >>> people. >> >> Is it not a slight exaggeration to say that Emacs is "constantly >> breaking things"? > > Is it? The build was just broken just recently. > Of course a development version is expected to break things from time to time. If you want stability, use stable releases. And I'd say that even the development version is pretty stable. It breaks occasionally, yes, and when it does it's during a very short period of time. >>> There are far more solutions to this problem than just unbinding keys >>> unconditionally for some unknown future case that nobody can figure >>> out. >> >> It's not "for some unknown future case that nobody can figure out", >> it's for a recurring problem that is becoming more and more important. >> More and more users use Emacs, the extensible editor, with third-party >> extension libraries, and these these third-party extension libraries >> cannot create global key bindings. > > There is already a space where users (and what third party packages can > recommend users to use) can bind their keys. > Yes, there is a space in which users can bind their keys, and as a matter of fact users can bind all keys the way they want it. Yes, third party packages can recommend users to use this or that key for their commands, they can also recommend users to use keys that are not reserved for them, and as a matter of fact packages can also bind all keys the way they want it (that's more or less what evil-mode does), as nobody is forcing them to follow the key binding conventions. The proposal is only to create a key space in which third party packages could automatically create global key bindings, without conflicting with Emacs core (that is, without rebinding any key bound in vanilla Emacs) and without conflicting with users' personal settings.