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: [Emacs-diffs] trunk r116461: Connect electric-indent-mode up with CC Mode. Bug #15478. Date: Wed, 26 Mar 2014 20:53:30 +0000 Message-ID: <20140326205330.GA3787@acm.acm> References: <20140316223509.GD3854@acm.acm> <20140319224231.GB4783@acm.acm> <20140322131350.GA3163@acm.acm> <20140322223454.GA3562@acm.acm> <20140324224055.GB3825@acm.acm> <87d2hb9hys.fsf@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1395867463 11512 80.91.229.3 (26 Mar 2014 20:57:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Mar 2014 20:57:43 +0000 (UTC) Cc: Stefan , emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 26 21:57:51 2014 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 1WSutS-0007SW-K0 for ged-emacs-devel@m.gmane.org; Wed, 26 Mar 2014 21:57:50 +0100 Original-Received: from localhost ([::1]:50310 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WSutS-0006k1-BS for ged-emacs-devel@m.gmane.org; Wed, 26 Mar 2014 16:57:50 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36259) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WSut1-00069J-Qn for emacs-devel@gnu.org; Wed, 26 Mar 2014 16:57:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WSusv-0001CY-SO for emacs-devel@gnu.org; Wed, 26 Mar 2014 16:57:23 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:16194 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WSusv-0001CK-JU for emacs-devel@gnu.org; Wed, 26 Mar 2014 16:57:17 -0400 Original-Received: (qmail 26702 invoked by uid 3782); 26 Mar 2014 20:57:15 -0000 Original-Received: from acm.muc.de (pD951A044.dip0.t-ipconnect.de [217.81.160.68]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 26 Mar 2014 21:57:14 +0100 Original-Received: (qmail 4068 invoked by uid 1000); 26 Mar 2014 20:53:30 -0000 Content-Disposition: inline In-Reply-To: <87d2hb9hys.fsf@yandex.ru> 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:171014 Archived-At: Hello, Dmitry. On Tue, Mar 25, 2014 at 03:37:15AM +0200, Dmitry Gutov wrote: > Alan Mackenzie writes: > >> > A mode-dependent or buffer-local dependent setting, as well as, rather > >> > than instead of. > >> We have that: electric-indent-local-mode and electric-indent-inhibit. > > OK, for electric-indent-local-mode, which is gradually becoming > > prominent. But I though electric-indent-inhibit was a variable for major > > modes, not users - a mode initialisation thing, rather than a user > > configuration variable. > This is usually the case with buffer-local dependent settings. They're > impossible to set via Customize (I think), so one doesn't usually think > of them as user options, but a user can modify such var in a hook, too. That's not what I meant. I meant something more like electric-indent-inhibit being a setting which defines a major mode rather than being a way of configuring it. > > b - Simplify `electric-indent-post-self-insert-function' such that it > > reindents only the line on which the self-inserting character is > > typed. > It would still need to handle presence of ?\n in `electric-indent-chars' > when that's the case. This value is somewhat special since the > line-to-be reindented would be the previous, not the current one. Yes to all of that. But I expressed myself precisely, and meant what I wrote. > > 2. For making RET indent the new line in programming modes: > > a - Bind RET to `newline-and-indent' and C-j to `newline' in > > `prog-mode-map' and possibly in certain other major mode maps (to be > > discussed). > I believe there's something to be said for consistency: having RET > indent line in some modes, but not others doesn't make much sense to me. Indentation (in the sense of what `indent-line-function' does) only makes sense in programming (etc.) modes. In text modes, and the like, indentation is, in practice, done with adaptive fill prefices. Having RET do `newline-and-indent' in Emacs Lisp Mode while doing `newline' in Text Mode makes a lot of sense to me. A trickier question is to identify which of the non-programming modes really want this sort of indentation. > There's a certain class of users who've been binding RET to > `newline-and-indent' for a long time (myself included), and I haven't > seen anyone mention only doing that in prog-mode, instead of globally. That was what we collectively decided last Autumn when the topic came up. You've seen me mention it. ;-) Richard Stallman alluded to it in his disgust at bug #16156, when what was bound to RET at the time zapped his indentation. I personally would not be unhappy at leaving the traditional binding in place for RET and C-j, but wouldn't mind them swapping in "indenting" modes. I'd object strongly to RET in text mode messing around with indentation. > > b - (Maybe) create a minor mode to restore RET and C-j to traditional > > bindings. > How hard can it be for a user to change the key bindings without a mode? Middling, not very. Such a minor mode might serve to damp down the inevitable complaints the change in defaults will provoke. > >> So make this bug report specific about a particular circumstance where > >> the behavior is undesirable, or about how hard it is to disable it. > > I think RMS's bug #16156, reproduced and being discussed on a parallel > > thread, is a good enough example, so there's not much point in me opening > > a new one. > This behavior, as described in the bug above, makes sense to me, so it's > clearly a personal preference. By "makes sense" I think you mean "seems a sensible thing to do". I take issue with you here and say that, in Text Mode, it's a bizarre thing to do. I can't think of any normal circumstances where this behaviour would be commonly desired; just how often in Text Mode do you not want RET just to insert a new line when you type it at the beginning of a line? -- Alan Mackenzie (Nuremberg, Germany).