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: electric-indent-mode: abolition of `newline' function is not the Right Thing. Date: Sun, 13 Oct 2013 17:28:41 +0000 Message-ID: <20131013172841.GA2498@acm.acm> References: <20131013101325.GA2621@acm.acm> <20131013140931.GC2621@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1381685450 10962 80.91.229.3 (13 Oct 2013 17:30:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 13 Oct 2013 17:30:50 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 13 19:30:53 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 1VVPVE-0006zK-Qj for ged-emacs-devel@m.gmane.org; Sun, 13 Oct 2013 19:30:52 +0200 Original-Received: from localhost ([::1]:33954 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VVPVE-0006xo-Ec for ged-emacs-devel@m.gmane.org; Sun, 13 Oct 2013 13:30:52 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36836) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VVPV4-0006xY-E6 for emacs-devel@gnu.org; Sun, 13 Oct 2013 13:30:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VVPUw-0003IA-VU for emacs-devel@gnu.org; Sun, 13 Oct 2013 13:30:42 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:16361 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VVPUw-0003Hv-Ec for emacs-devel@gnu.org; Sun, 13 Oct 2013 13:30:34 -0400 Original-Received: (qmail 91933 invoked by uid 3782); 13 Oct 2013 17:30:32 -0000 Original-Received: from acm.muc.de (pD9519254.dip0.t-ipconnect.de [217.81.146.84]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 13 Oct 2013 19:30:31 +0200 Original-Received: (qmail 2783 invoked by uid 1000); 13 Oct 2013 17:28:41 -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:164181 Archived-At: Hello, Stefan. On Sun, Oct 13, 2013 at 12:22:33PM -0400, Stefan Monnier wrote: > > :-) Of course there are workarounds, but that's not the point. > > There are approximately 198 calls to `newline' in the Emacs Lisp > > sources, and an unknown further number in other Lisp files and users' > > .emacsen. Some of these calls are going to get broken by the > > effective change to `newline'. > Right. But the problem is that this is not specific to > electric-indent-mode: newline calls self-insert-command, which runs > expand-abbrev and (since Emacs24) post-self-insert-hook. Any caller > which only wants a \n and no extra doo-dads should not call `newline'. > electric-indent-mode just makes this problem more apparent. Sorry Stefan, but that is disingenuous. If you look again at `electric-indent-post-self-insert-function', you will see that that function deliberately converts `newline' into `newline-and-indent'. It even says so in the comments. _This_ is the problem. What is the justification for this extension in functionality of `newline' to do the same as `newline-and-indent'? And people calling `newline' do not simply want a \n. They want abbreviations to be processed, they want auto-fill to be run, trailing space to be removed from otherwise blank lines, and so on. What they _don't_ want is indentation inserted on the new line. Please take this indent-newline functionality out of e-i-post-s-i-function (or let me do it). Incidentally, each call of e-i-post-s-i-function creates a new marker, bound to the let variable `before'. This is not set to point nowhere before `before' becomes unbound. I think it probably should. > Stefan -- Alan Mackenzie (Nuremberg, Germany).