From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Default behaviour of RET. Date: Fri, 18 Oct 2013 15:52:22 -0400 Message-ID: References: <20131013140931.GC2621@acm.acm> <20131013172841.GA2498@acm.acm> <525D8946.4070406@gmx.at> <20131016171240.GA3125@acm.acm> <525EDC50.8010401@gmx.at> <20131016192642.GD3125@acm.acm> <87mwm8g61e.fsf@uwakimon.sk.tsukuba.ac.jp> <20131018170320.GC2569@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1382125964 18967 80.91.229.3 (18 Oct 2013 19:52:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 18 Oct 2013 19:52:44 +0000 (UTC) Cc: martin rudalics , "Stephen J. Turnbull" , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 18 21:52:47 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 1VXG6G-0005MV-Hj for ged-emacs-devel@m.gmane.org; Fri, 18 Oct 2013 21:52:44 +0200 Original-Received: from localhost ([::1]:59209 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VXG6G-00011J-3C for ged-emacs-devel@m.gmane.org; Fri, 18 Oct 2013 15:52:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34537) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VXG66-000109-Gw for emacs-devel@gnu.org; Fri, 18 Oct 2013 15:52:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VXG5z-0006Am-7T for emacs-devel@gnu.org; Fri, 18 Oct 2013 15:52:34 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:34259) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VXG5z-0006AY-1G for emacs-devel@gnu.org; Fri, 18 Oct 2013 15:52:27 -0400 Original-Received: from faina.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id r9IJqM0l017745; Fri, 18 Oct 2013 15:52:22 -0400 Original-Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id C866CB4162; Fri, 18 Oct 2013 15:52:22 -0400 (EDT) In-Reply-To: <20131018170320.GC2569@acm.acm> (Alan Mackenzie's message of "Fri, 18 Oct 2013 17:03:20 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4735=0 X-NAI-Spam-Version: 2.3.0.9362 : core <4735> : inlines <156> : streams <1058205> : uri <1569417> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 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:164327 Archived-At: >> > The traditional docstring says that it moves to the left margin and >> > handles auto-filling. Eli's suggestion of `(insert "\n")' doesn't do >> > that, and it's not what `newline' does when corrupted by >> > `electric-shock-mode'. But I think it's useful behavior, and I think >> > programs should be able to rely on it (as opposed to users who can >> > modify the behavior of `One-Flew-Over-the-Cuckoos-Nest-mode' by >> > removing ?\n, or not invoke the mode in the first place). >> I can't remember ever seeing a piece of code which wants "the Emacs-23 >> newline behavior". Usually it either wants to (insert "\n") or it wants >> to simulate hitting RET. > I gave an example of such code in the post which opened this thread. To > recap: > (newline) > (insert "(vi)") > (fill-paragraph) > The `-and-indent' behaviour messes up the indentation of "(vi)" and > causes it to get re-attached to the previous paragraph. I see why the above doesn't want the "simulate RET" behavior. But I don't see why it wouldn't work just fine with the (insert "\n") behavior? >> This discussion would benefit from actual examples of code that >> fall into neither "do whatever RET does" nor "insert \n". > See above. Any code which is interested in filling (or, possibly, even > margins, if anything actually uses these) will get broken by the > `-and-indent'. "any code which..." is not concrete. Stefan