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: Suggested experimental test Date: Mon, 22 Mar 2021 10:05:19 +0000 Message-ID: <271290d7aa5560786ded@heytings.org> References: <831ba60af0cbfdd95686@heytings.org> <87mtuxj8ue.fsf@gnus.org> <9088e12cb3169cdcdbc4@heytings.org> <9088e12cb3a70cbf66aa@heytings.org> <9088e12cb381e11e6d32@heytings.org> <9088e12cb36020430ea2@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="23168"; 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 Mon Mar 22 11:11:51 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 1lOHXL-0005rU-6C for ged-emacs-devel@m.gmane-mx.org; Mon, 22 Mar 2021 11:11:51 +0100 Original-Received: from localhost ([::1]:60360 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lOHXK-0002II-3u for ged-emacs-devel@m.gmane-mx.org; Mon, 22 Mar 2021 06:11:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54686) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lOHR7-0005R0-Sq for emacs-devel@gnu.org; Mon, 22 Mar 2021 06:05:26 -0400 Original-Received: from heytings.org ([95.142.160.155]:40348) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lOHR5-00010r-Bw; Mon, 22 Mar 2021 06:05:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1616407520; bh=7Py/YEjGKTeYma7RnKItjf9dOh2eqUxsibYiFXMGwfg=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=LpRE0QjvZpQXKpYsX38yf//c2+Mjmy+I+1QXUeFOoPGwqak+LrGojVh4/8k4OMgf0 GOYvnV7BWZv1F2yWo8l3Bd3/MQL943KWXyYZgDDMgJTSE7rcTeOpNXjXlX+CBbcQ/2 ExExdUoMZQ0pbOJeDzp8O0BdKdSsBdY/jJ6QXnUL4fdhX7K4WOQA1NC9ag1VOc8baj 9EVRUX+DNT1QHDNeFZw5JJqSuRWt1h8/RbJ2sJDdQK1sKgoiqu2K4LlMFYxqtfl7NE 5H1S14N11xYswvgx49pS92MO0xeJCp9/zgmrIzvtXxfDRZyunJqWvrWXErPm6PFrw4 H5X65/Zr6/N+g== 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:266740 Archived-At: >>> Neither center-line nor center-paragraph have been given an >>> alternative binding. The same is also applicable for facemenu. >>> Despite requests for it. >> >> This is another topic, unrelated to the current one, and as I said >> earlier I'm currently experimenting ways to readd these commands. I do >> this thinking specifically of you. > > Thanks, I'm flattered, but I'd hope you rather consider those who do not > read this list first than grumpy Emacs users. > I do consider them, too. But I think that "grumpy Emacs users" who express themselves also speak for (at least some of) those who do not read this list. >> Moreover, polling with abstract questions is not a good way to discuss >> UI changes. The point of conducting experiments on the trunk is that >> users concretely experiment potential changes. > > I think you can make these questions less abstract, even to the point of > a yes / no question. "Do you use M-o (frobnicate-line)? Yes/No.". > Sending out a questionare for each release would be unrealistic, > That doesn't answer the main question: how do you concretely poll these users? and what would you consider to be a significant enough fraction of Emacs users for the poll to be representative? Would 500 answers be enough? 1000? 5000? 10000? What would you do with the result of such a poll? What if only 50 or 100 in those 10000 answer "yes"? Should the feature be kept for those 50 or 100? Moreover the result of a yes/no poll like "Do you use M-o (frobnicate-line)?" is not very useful: "No, I don't use it, because I did not know it exists" "No, I don't use it, I know it exists and I'm sure I'll never use it" "No, I don't use it at the moment, but I may use it in the future" "Yes, I do use it, but I use viper-mode/evil-mode, so it's not bound to M-o" "Yes, I do use it, but I bind it to another key in my init file and use M-o for something else" "Yes, I do use it, but not frequently, so I wouldn't mind if it were moved to another key" "Yes, I do use it, but not frequently, and I wouldn't mind if I had to use M-x frobnicate-line instead" "Yes, I do use it frequently, but I wouldn't mind if it were moved to another key" "Yes, I do use it frequently, and would prefer that it remains on the same key" "Yes, I do use it frequently, and would rebind it to the current key in my init file if its binding changed" ... are all valid answers with very different consequences, that cannot be seen in a yes/no poll. > > so one could accumulate a set of proposal in release 20, send it out > during release 21, and delibrate and implement for 22. > That would be unrealistic, it would mean a four to six years waiting period before an UI change can be implemented, long enough to discourage anyone in advance to even envision the possibility of proposing such a change. >> Fortunately, such changes are easy to revert for users who would >> dislike them, and the way to revert them is documented in the NEWS >> file. > > From my experience, it isn't the case. > Of course it is, for example the way to revert the M-o change is documented in the NEWS file, both for those who would like to only revert facemenu, and for those who would like to only revert the two center-foo commands. >> Another example, which I forgot in my previous list, is C-c, which was >> changed from exit-recursive-edit to a prefix key in Emacs 16, and >> exit-recursive-edit was moved to C-M-c. > > Changing the semantics slightly is I think less annoying than completle > removing a keybinding. > Changing "C-c" from exit-recursive-edit to a prefix key was not changing its semantics slightly, and the proposed experiment in this thread is not about completely removing a key binding, it is about changing its semantics slightly.