From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Alfred M. Szmidt" Newsgroups: gmane.emacs.devel Subject: Re: Suggested experimental test Date: Sun, 21 Mar 2021 20:40:01 -0400 Message-ID: References: <831ba60af0cbfdd95686@heytings.org> <87mtuxj8ue.fsf@gnus.org> <9088e12cb3169cdcdbc4@heytings.org> <9088e12cb3a70cbf66aa@heytings.org> <9088e12cb381e11e6d32@heytings.org> <9088e12cb36020430ea2@heytings.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37597"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Mar 22 01:40:42 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 1lO8cc-0009fJ-FB for ged-emacs-devel@m.gmane-mx.org; Mon, 22 Mar 2021 01:40:42 +0100 Original-Received: from localhost ([::1]:38002 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lO8cb-0004hl-H1 for ged-emacs-devel@m.gmane-mx.org; Sun, 21 Mar 2021 20:40:41 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40912) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lO8bx-0004H6-ST for emacs-devel@gnu.org; Sun, 21 Mar 2021 20:40:01 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:46939) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lO8bx-0004XK-DD; Sun, 21 Mar 2021 20:40:01 -0400 Original-Received: from ams by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1lO8bx-0005ic-1K; Sun, 21 Mar 2021 20:40:01 -0400 In-Reply-To: <9088e12cb36020430ea2@heytings.org> (message from Gregory Heytings on Sun, 21 Mar 2021 23:46:42 +0000) 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:266731 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. >> Please have a look at the proposed experiment: it moves open-line to >> repeated C-o. > > A proposal is not reality, and such a behaviour would be yet again > beyond annoying. How about doing polls first instead of doing this > blind experiments What kind of poll would you like to see? What would you consider to be a significant enough fraction of Emacs users? How would you poll them? There has been a survey a few months ago, and in spite of the fact that there were more than 7000 replies, many complained that the results were not representative. The best polling suggestion I've seen so far has been from rms, and those have had good track records over the years. 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, so one could accumulate a set of proposal in release 20, send it out during release 21, and delibrate and implement for 22. One could also add some extra details, like if the change is for something in a very recent version such a long cycle isn't required, but if it is has existed since Emacs 18 it is. > where it will be far to late when these changes sneak into Emacs for > them to be changed back. 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. The usual argument is that "we just changed it, lets keep it for a bit more" -- and then it becomes permanent. As I said, there have been many changes even to the C-LETTER and M-LETTER keys in the past, when it was thought that the key in question could be used in a better way. 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. Elided much of that since if I didn't, my reply would become a rather longer rant. Changing the semantics slightly is I think less annoying than completle removing a keybinding. The bare minimum I think is that if removing a long standing keybinding, it should at least get a new one. Make it a three stage rocket, M-s got punted to M-o M-s .. this could get punted to H-x M-o M-s (or something slighly more paltable) ... and then removed. With actual polls inbetween to get a feel of what people outside this list prefer, but also a heavier handed touch of deciding on an actual policy of how exactly bindings should be mapped. The way Emacs did it is that C- is smaller than M- which is smaller than C-M-. Right now, there is no such decision process, and its quite random. As an example if I do not recall incorrectly, C-o used to insert new line, M-o would also adjust for indentation, and C-M-o would keep the same indentation as the current line. It is these small things that make Emacs make sense for new users.