From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Default behaviour of RET. Date: Sun, 20 Oct 2013 14:55:13 +0000 Message-ID: <20131020145513.GC3484@acm.acm> References: <525EDC50.8010401@gmx.at> <20131016192642.GD3125@acm.acm> <87mwm8g61e.fsf@uwakimon.sk.tsukuba.ac.jp> <20131018170320.GC2569@acm.acm> <20131018204551.GC3012@acm.acm> <20131019105836.GA2991@acm.acm> <762fa4a6-1a42-48b2-97ba-0f3ab7ef7ba5@default> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1382281049 31452 80.91.229.3 (20 Oct 2013 14:57:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2013 14:57:29 +0000 (UTC) Cc: martin rudalics , "Stephen J. Turnbull" , Stefan Monnier , emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 20 16:57:32 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VXuRf-00017V-UL for ged-emacs-devel@m.gmane.org; Sun, 20 Oct 2013 16:57:32 +0200 Original-Received: from localhost ([::1]:36374 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VXuRf-0003yU-Jq for ged-emacs-devel@m.gmane.org; Sun, 20 Oct 2013 10:57:31 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59266) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VXuRV-0003mY-4Y for emacs-devel@gnu.org; Sun, 20 Oct 2013 10:57:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VXuRN-0007Yk-PN for emacs-devel@gnu.org; Sun, 20 Oct 2013 10:57:21 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:43703 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VXuRN-0007YZ-Fz for emacs-devel@gnu.org; Sun, 20 Oct 2013 10:57:13 -0400 Original-Received: (qmail 21768 invoked by uid 3782); 20 Oct 2013 14:57:12 -0000 Original-Received: from acm.muc.de (pD951BC97.dip0.t-ipconnect.de [217.81.188.151]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 20 Oct 2013 16:57:10 +0200 Original-Received: (qmail 5554 invoked by uid 1000); 20 Oct 2013 14:55:13 -0000 Content-Disposition: inline In-Reply-To: <762fa4a6-1a42-48b2-97ba-0f3ab7ef7ba5@default> User-Agent: Mutt/1.5.21 (2010-09-15) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 8.x X-Received-From: 193.149.48.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:164392 Archived-At: [ personal mail ] Hi, Drew. On Sat, Oct 19, 2013 at 08:07:35AM -0700, Drew Adams wrote: > > OK. I've done a find-grep in .../lisp for all *.el matching > > '^[^;\n]*(newline\([ )]\|$\)'. There are 199 matches. > > There are 27 occurences of the exact string "(or (bolp) (newline))", > > which looks like making sure point is at BOL in an output file. > I haven't been following this thread; sorry. I don't have any calls > to `newline' in my code, FWIW. > Is the following a reasonable summary of the question & positions? > 1. One position wants to change the behavior of `newline', so that > all uses of it automatically benefit from the new behavior. > 2. The other position wants to keep `newline' as it is, perhaps for > some existing calls and in any case for some future calls. This > position holds that the "old" behavior can be useful in some contexts. More or less. > Sounds like two different functions are in order, for the old and new > behaviors - au choix. If so, it's not a big deal to update the Emacs > sources one way or the other. I think I've managed to persuade SM of that, now. But I'm not convinced his latest patch is the right thing. It's probably the best I'll manage, though. > But in case there is 3rd-party code that uses `newline', it seems > like the prudent choice would be to keep the existing name for the > existing behavior and give the new behavior a new name. 3rd-party > code that wants to "upgrade" to the new behavior can do that. And > there would be no surprises. That command already exists, and is called `newline-and-indent'. > Is there more to it that this? 'Fraid so! The mechanism by which `newline' was changed was by adding a function to `post-self-insert-hook' when electric-indent-mode is active, and this function checked whether a newline had been added, and indented the new line if it had. My task, which seems to have been inordinately difficult, was to persuade SM that this roundabout means of turning `newline' into `newline-and-indent' is just as bad as the direct means. It's been exhausting. I hope the argument has now been won. -- Alan Mackenzie (Nuremberg, Germany).