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: Wed, 24 Mar 2021 08:42:42 +0300 Message-ID: References: <831ba60af0cbfdd95686@heytings.org> <87mtuxj8ue.fsf@gnus.org> <9088e12cb3de3d30abf1@heytings.org> <8735wnjsum.fsf@gnus.org> <87tup3hwat.fsf_-_@gnus.org> <834kh39fvj.fsf@gnu.org> <271290d7aaec41df5fde@heytings.org> <83k0py8f5k.fsf@gnu.org> <22aaf0fadd2892c6dc2e@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="33093"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.0.6 (2021-03-06) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Mar 24 06:46:03 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 1lOwLC-0008SX-SY for ged-emacs-devel@m.gmane-mx.org; Wed, 24 Mar 2021 06:46:02 +0100 Original-Received: from localhost ([::1]:40644 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lOwLB-0005qY-Sh for ged-emacs-devel@m.gmane-mx.org; Wed, 24 Mar 2021 01:46:01 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58430) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lOwJN-0004iC-2P for emacs-devel@gnu.org; Wed, 24 Mar 2021 01:44:09 -0400 Original-Received: from stw1.rcdrun.com ([217.170.207.13]:56065) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lOwJ2-0008SG-7T; Wed, 24 Mar 2021 01:44:08 -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.00000000605AD190.00003272; Tue, 23 Mar 2021 22:43:44 -0700 Mail-Followup-To: Gregory Heytings , Eli Zaretskii , emacs-devel@gnu.org Content-Disposition: inline In-Reply-To: <22aaf0fadd2892c6dc2e@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:266921 Archived-At: * Gregory Heytings [2021-03-23 17:17]: > > > > > > > I use C-o (usually followed by C-n) many times a day, > > > > > > instead of , in order to suppress re-indentation > > > > > > of the current line in cases where that re-indentation > > > > > > will be incorrect for my purposes**. > > > > > > > > > > Oh, I see -- it's useful as an alternative to `RET' exactly > > > > > when re-indentation does the wrong thing? > > > > > > > > Yes, but not only that -- it doesn't move point to the next > > > > line, unlike RET. > > > > > > Why should a control key must be reserved forever for that very > > > specific purpose, and for that very specific purpose only, in the > > > default Emacs bindings? > > > > Opening an empty line is a very useful editing primitive, not unlike > > going to the next line with RET. > > > > I'd bet it is useful, as it is, only for 0.5% of Emacs users, perhaps even > less. No other editor I know has that feature. It cannot be argument here that other editors don't have features built-in into Emacs. Those are known facts. Emacs is advanced editor. Other editors simply don't have features of Emacs, unless they are Emacs-like. But there are several Emacs-like editors: Edwin in MIT Scheme, mg in OpenBSD, e3em, Zile, Zile on Guile, Emacs on Guile, those are once that I use from time to time here, including as a replacement for emacsclient (when something goes wrong). I have used those multiple times during last month. More references: https://wiki.gentoo.org/wiki/Project:Emacs/Emacs-like_editors Now when you bet, I also bet you don't use Emacs-like editors, and I am unsure how much you use Emacs beside those other editors you use. Another feature that many editors don't have is macro feature, editors that do have macro features are always more advanced than others. Because other editors do not have that feature, should we disable macros in Emacs? And then which other editors do you mention? Can we get the disclosure? Your personal experiences should or could be reasoned to understand those features you are referring to. > And I'd bet that 90% of those 0.5% would be happier with a better > open-line primitive, for example one which can be called when point > is in the middle of a line, like "o" and "O" in vi. I have mentioned my personal case and I said I would not like changing default of C-o or getting habit with my personal customizations to have C-o behave like O in vi. In relation to "o" in vi, I do not open new line below the current one, but I agree that quicker key binding would be nice. "o" from vi in Emacs is easily replaced with C-o as instead of using the current line, then I would be simply using one line below. - "o" in vi -- frequently used, it opens new line after current line, regardless where is cursors located. In Emacs: go to one line below, beginning of line, press C-o - "O" in vi - frequently used, opens new line before current line and places cursor at beginning of the line for writing, in Emacs, C-a C-o does the same. Again, I would not like changing Emacs default behavior as for me who works on various Emacs versions, including some older like few years (OS never get updated on those computers) -- including using Emacs-like editors frequently on remote VPS-es or remote computers, sometimes on personal computer. > The discussion showed that those who use it use it at BOL, and that > it wasn't used alone, but as part of a sequence, for example C-a C-o > or C-o C-n. Nobody even mentioned the fact that open-line uses the > fill-prefix and the left-margin. > > As I said, an improved version of that command could for example be put on > M-RET. Here's an attempt: > > (defun smart-open-line (&optional arg) > (interactive "*p") > (when (> arg 0) > (beginning-of-line) > (let ((p (point-marker))) > (dotimes (_ arg) (insert "\n")) > (goto-char p))) > (when (< arg 0) > (setq arg (abs arg)) > (beginning-of-line) > (forward-fine 1) > (dotimes (_ arg) (insert "\n")) > (forward-line -1))) > (global-set-key (kbd "M-RET") 'smart-open-line) I have tried that version, it may be better than this one below that I have ready -- but remember, I am not using it and do not want to depend on it, that it does not change my finger work when I am working on un-customized Emacs versions. (defun my-C-o () "Opens new line regardless where is cursor positioned." (interactive) (move-beginning-of-line nil) (open-line 1)) but I would like to ask not to bind M-RET to something by default in Emacs, as it is used very efficiently in the package Hyperbole, and I recommend that you try using Hyperbole to understand M-RET > And even assuming that it is useful as it is, that doesn't answer > the main question: why should a control character key be reserved > forever for that very specific purpose, and for that very specific > purpose only? Because it is default for many years, learned and used by people and adopted by other Emacs-like editors. You can make then same question like why should C-a be used to jump to beginning of the line or C-f to move one char forward. Nothing is forever.