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: Tue, 23 Mar 2021 14:15:12 +0000 Message-ID: <22aaf0fadd2892c6dc2e@heytings.org> 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> 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="8520"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Mar 23 15:18:00 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 1lOhr5-000261-K2 for ged-emacs-devel@m.gmane-mx.org; Tue, 23 Mar 2021 15:17:59 +0100 Original-Received: from localhost ([::1]:44460 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lOhr4-0004by-J2 for ged-emacs-devel@m.gmane-mx.org; Tue, 23 Mar 2021 10:17:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42620) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lOhoZ-0001VO-3g for emacs-devel@gnu.org; Tue, 23 Mar 2021 10:15:23 -0400 Original-Received: from heytings.org ([95.142.160.155]:42174) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lOhoV-00005Z-Ou; Tue, 23 Mar 2021 10:15:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1616508912; bh=eD0YZ4y+QZRI5XPtbBjPObd1Yh13uHhQN8jcqDpPuMg=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=JQQIvsEGY5TirSO3CwomXbsgGXpP3Vd7p2D6eOs1YjF2EPK0rliCaU9AiJfUzUFjM eBlI4tY+SVRM07LLXZ427utdreCLYcpGyvKDVidrh3FF6tOD1ltCJja/bV+hvhF8EA fnVVjEpRlSl91PxTWnlqMRK9gsj8/PSc2XhWEyD0go0E5/746a0O+174TFBHrLqh23 9Iz96MqlECWdf3fv1K1d0QR9NPpG0OzkW/OVsPtkMssu0wGSs00pjCdDMMluw8gi10 xQzMjV+5a5/5Ogmj16h69Jc8JGgTDqNdIVv5CvlZJWof9Hqxy/wbMhFXpgsI7sjGyc 02I+8u1H8QsQA== In-Reply-To: <83k0py8f5k.fsf@gnu.org> 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:266876 Archived-At: >>>>> 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. 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. 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-line 1) (dotimes (_ arg) (insert "\n")) (forward-line -1))) (global-set-key (kbd "M-RET") 'smart-open-line) 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? > > Trying to change that will always cause staunch resistance, especially > when the purpose for which this is done is vague and not perceived as > important enough by enough people. > I could have clarified the purpose indeed, but the risk would have been to start two parallel discussions.