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: Sat, 19 Oct 2013 10:58:36 +0000 Message-ID: <20131019105836.GA2991@acm.acm> References: <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> <20131018204551.GC3012@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1382180455 27385 80.91.229.3 (19 Oct 2013 11:00:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 19 Oct 2013 11:00:55 +0000 (UTC) Cc: martin rudalics , "Stephen J. Turnbull" , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 19 13:00:58 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 1VXUH9-0005M0-To for ged-emacs-devel@m.gmane.org; Sat, 19 Oct 2013 13:00:56 +0200 Original-Received: from localhost ([::1]:32835 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VXUH9-0001se-GU for ged-emacs-devel@m.gmane.org; Sat, 19 Oct 2013 07:00:55 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51765) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VXUGz-0001sW-MV for emacs-devel@gnu.org; Sat, 19 Oct 2013 07:00:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VXUGr-0004aV-7L for emacs-devel@gnu.org; Sat, 19 Oct 2013 07:00:45 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:37228 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VXUGq-0004Wn-Nb for emacs-devel@gnu.org; Sat, 19 Oct 2013 07:00:37 -0400 Original-Received: (qmail 70958 invoked by uid 3782); 19 Oct 2013 11:00:34 -0000 Original-Received: from acm.muc.de (pD951A1DC.dip0.t-ipconnect.de [217.81.161.220]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 19 Oct 2013 13:00:33 +0200 Original-Received: (qmail 3418 invoked by uid 1000); 19 Oct 2013 10:58:36 -0000 Content-Disposition: inline In-Reply-To: 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:164354 Archived-At: Hello, Stefan. On Fri, Oct 18, 2013 at 09:59:54PM -0400, Stefan Monnier wrote: > > The point is that there are a near infinite number of invocations of > > `newline' in the wild, and an unknown proportion of these, possibly > > quite high, will depend on `newline' doing precisely what its doc string > but also possibly quite low. Just how low does it have to be before we can ignore it? > > says. Their existence makes the utility of electric-indent-mode, at the > > moment, questionable. > As long as we're in the "unknown proportion", we can't tell. > >> >> 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. > > I've given you a concrete example of such code, several times. > Right, but I said "examples" not "example". So far I've seen one > concrete example, from your ~/.emacs (i.e. a problem that will affect > O(1) user). That's not very compelling. 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. For example, in uce.el, we have the following code at L359: ;; If message doesn't end with a newline, insert it. (goto-char (point-max)) (or (bolp) (newline))) . In org-datetree.el, we have this, at L83: (goto-char (point-max)) (or (bolp) (newline)) (org-datetree-insert-line year)) . This same idiom appears two other times in this file alone. I looked at quite a few other occurences of "(or (bolp) (newline))" and all the ones I could understand instantly were about ensuring point is at BOL, as indeed was my own personal code. > Stefan -- Alan Mackenzie (Nuremberg, Germany).