From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jean Louis Newsgroups: gmane.emacs.devel Subject: Re: Suggested experimental test Date: Mon, 22 Mar 2021 21:03:11 +0300 Message-ID: References: <831ba60af0cbfdd95686@heytings.org> <87mtuxj8ue.fsf@gnus.org> <9088e12cb3de3d30abf1@heytings.org> <8735wnjsum.fsf@gnus.org> <271290d7aa8b3d984968@heytings.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34340"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.0.6 (2021-03-06) Cc: Lars Ingebrigtsen , 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 19:10:12 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 1lOP0G-0008qB-DT for ged-emacs-devel@m.gmane-mx.org; Mon, 22 Mar 2021 19:10:12 +0100 Original-Received: from localhost ([::1]:36022 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lOP0F-0006Ej-Bf for ged-emacs-devel@m.gmane-mx.org; Mon, 22 Mar 2021 14:10:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56268) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lOOz4-0005I0-Pu for emacs-devel@gnu.org; Mon, 22 Mar 2021 14:08:59 -0400 Original-Received: from stw1.rcdrun.com ([217.170.207.13]:51149) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lOOyw-0007pX-Eq for emacs-devel@gnu.org; Mon, 22 Mar 2021 14:08:58 -0400 Original-Received: from localhost ([::ffff:41.202.241.53]) (AUTH: PLAIN securesender, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 000000000001E0AB.000000006058DD0D.000076B4; Mon, 22 Mar 2021 11:08:13 -0700 Mail-Followup-To: Gregory Heytings , Lars Ingebrigtsen , emacs-devel@gnu.org Content-Disposition: inline In-Reply-To: <271290d7aa8b3d984968@heytings.org> Received-SPF: pass client-ip=217.170.207.13; envelope-from=bugs@gnu.support; helo=stw1.rcdrun.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, 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:266771 Archived-At: * Gregory Heytings [2021-03-22 20:08]: > > > > > Well... the suggested experiment does not remove C-o, it changes > > > > C-o in a way that is, I believe, painless. > > > > > > Sorry; I didn't read the patch carefully. So it basically moves > > > `C-o' to `C-o C-o' (and makes the `C-o' prefix open for new > > > commands)? > > > > > > I don't use `C-o' myself, so I can't really say to what degree this > > > would be annoying or not for users. Any `C-o' users who have an > > > opinion here? > > > > For now I count 3 people from mailing lists who already objected to it, > > including me. > > > > I've only seen one (you), and perhaps a second one (Alfred), but I'm not > quite sure because he initially thought that open-line would be > removed. Plus Rudolf Schlatte who explained using `C-o` frequently. Those are 3 for now. > > How do you Lars insert new lines, before the current line with cursor? > > > > I can't speak for Lars, but if this is something that I frequently needed, I > would either learn the C-p C-e C-m sequence, or make it a command in my init > file, for example: > > (global-set-key (kbd "M-RET") (lambda () (interactive) (previous-line) (end-of-line) (newline-and-indent))) > > (M-RET has a similar purpose in org-mode.) That is good that you tell how you do it. Sounds funny to me, obviously we have different ways to getting to same result. I am inserting lines frequently and I would never think of using `C-p C-e C-m` -- which now makes sense, as from your side you probably do not insert lines, so for you `C-o` does not make sense. In considerations if some change is useful one has to consider also what other people are doing when they want to achieve functionality X, in this case `open-line` which is often used to insert new lines before the current one. >From your viewpoint, you are already using 3 keys to get to the result, for you is fine to replace `C-o` with `C-o C-o` as that one would any way shorten your own 3-keys sequence. But it looks like you do not even use C-o to open a new line, like `C-a C-o` seems something you did not use when cursor is not at beginning of wthe line. Meeting users and their behavior of editing in relation to specific feature is better, it is more productive, and gives more insights. > > Gregory, don't you think that 3 users including me who expressed their > > objections is not part of the experiment already? > > No, precisely because nobody actually experimented the potential > change. You cannot give an opinion on a change before experimenting > it for some time, say, at least a day. I am also thankful for that insight. For me, the experiment begins with the simple introduction at the moment of understanding it. For you it begins then when people actually start using it -- but you miss the fact that some people would not even start experimenting with it as they do not find it useful in the first place and do not want to change their habits. Experiment should not be conducted for the sake of experiment alone. It should be conducted to improve the usability or user experience with editor. In my opinion, experiments of changing key bindings should not be conducted with the purpose of introduction of new commands, but with the purpose of making usability or user experience or efficiency of editing better. Checklist for key binding experiments: 1. [ ] - Conduct research, is the key binding included in Emacs-like editors like Emacs on Guile, Zile on Guile, Zile, mg, e3m, MIT Scheme's Edwin, and maybe few other similar. 2. [ ] - Conduct online research if the command and key binding is frequently asked for by users, review occurences of mentioning the command and the key binding on EmacsWiki, manual, and other websites by using search engines. 3. [ ] - Instead of proposing the experiment too early, ask people how they are doing the functionality X -- don't ask if they are using specific command `you-name-it`; example is how I have asked you and Lars "How are you inserting new line from the current line?" -- and I am still curious how people are doing it. Question is not really related to `C-o` or `open-line` but to the result of it that could be achieved by various different ways. 4. [ ] - Decide what is your proposal to replace key binding, define it well, but don't publish on the mailing list (or do publish). 5. [ ] - Compare your proposal to the existing key binding and the command and make list of reasons why would your replaced key binding be more useful and beneficial for users, user experience or efficiency in editing than the already present key binding. For example if you have never used `C-o` it would be better to fully understand its usage as it can be you have quite different idea on how to insert new lines. But if you did not understand usage of `C-o` you should or could assume that your proposal is maybe biased by your own user experience. 6. [ ] - After the review, if you think your proposal is improving editing efficiency, or usability, or user experience, then propose the new change. Provide patch, initiate experiments, or ask people about it. 7. [ ] - Do not assume that experiment, objections, protests, begin with the actual invokation of the experiment, as people on the mailing list already understand by reading the Emacs Lisp code, consider their opinions as valid objections and count them even if they did not practically experiment with it -- as they obviously did not find it practical to experiment with. 8. [ ] - Count pro and contras. Even if there are more positives for your experiment, do not assume that it would really enhance user experience, or that you got users' feedback, as we are on this mailing list testing Emacs in development stage, while users will be using it in their daily life. Consider various implications, breaking habits of millions of people. Consider butterfly effects before introducing it in new stable version of Emacs. Jean