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: Sat, 22 Mar 2014 22:34:55 +0000 Message-ID: <20140322223454.GA3562@acm.acm> References: <20140308225820.GB2726@acm.acm> <20140309123711.GA2615@acm.acm> <20140316223509.GD3854@acm.acm> <20140319224231.GB4783@acm.acm> <20140322131350.GA3163@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1395527930 8136 80.91.229.3 (22 Mar 2014 22:38:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 22 Mar 2014 22:38:50 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 22 23:38:59 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 1WRUZ8-0002rH-02 for ged-emacs-devel@m.gmane.org; Sat, 22 Mar 2014 23:38:58 +0100 Original-Received: from localhost ([::1]:58331 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WRUZ7-0004ea-Fu for ged-emacs-devel@m.gmane.org; Sat, 22 Mar 2014 18:38:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49186) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WRUYw-0004eN-Ok for emacs-devel@gnu.org; Sat, 22 Mar 2014 18:38:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WRUYp-0000nq-DV for emacs-devel@gnu.org; Sat, 22 Mar 2014 18:38:46 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:59689 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WRUYp-0000nm-2o for emacs-devel@gnu.org; Sat, 22 Mar 2014 18:38:39 -0400 Original-Received: (qmail 31378 invoked by uid 3782); 22 Mar 2014 22:38:36 -0000 Original-Received: from acm.muc.de (pD9518C69.dip0.t-ipconnect.de [217.81.140.105]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 22 Mar 2014 23:38:35 +0100 Original-Received: (qmail 4474 invoked by uid 1000); 22 Mar 2014 22:34:55 -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:170819 Archived-At: Hello, Stefan. On Sat, Mar 22, 2014 at 12:14:54PM -0400, Stefan wrote: > > The indentation of an elisp line of code is solely dependent on the > > the lines before it - its indentation is completely determined before > > any of its contents are typed in. Therefore there is nothing to be > > gained by reindenting this line at any subsequent time, i.e. electric > > indentation. Whether a user uses C-j or RET to terminate this line > > is irrelevant. > Then I have no idea what you're talking about. "electric-indent" to me > means "try to keep code indented without having to hit TAB". The actual definition of "electricity" is found in the Emacs manual, page "Electric C", where it has been for a very long time indeed. It runs as follows: In C mode and related modes, certain printing characters are "electric"--in addition to inserting themselves, they also reindent the current line, and optionally also insert newlines. . If you redefine the "electric" in "electric-indent" as you have done, you conflate unrelated topics, and both your thought patterns and the code end up a mess. It is not helpful to construe `newline-and-indent' as somehow being "electric". > In Elisp, without electric-indent you have to use C-j or TAB if you > want your code indented. So whether the user hits C-j or RET is > relevant. No. To keep Elisp properly indented, you merely have to depress whichever key is bound to `newline-and-indent', whether that be RET, or C-j, or whatever. Electric indentation doesn't come into it. > > Using electric indentation on RET is poor, because it only works when you > > actually type a RET (or a C-j). > That doesn't mean it's poor. Just that it's not sufficient. > And I fully agree on this, which is why we have electric-indent-chars. > > This is often not the case, e.g. when you open up a line (e.g. with > > C-M-o) then type in a new line of code. > Last I checked, RET is used more commonly than C-M-o. Yes, but the point still stands. You open up a fresh line, by RET, and type code into it, but don't want to type RET/C-j at the end of it. You'll want electric indentation on some other character you've just typed. > > If you are typing in comments at the end of code lines, you won't want > > electric indentation messing up their alignment. > If auto-indentation gets it wrong, then indeed electric-indent will get > in the way. That's true whether RET is electric or not. No. If electric indentation has already happened after typing the semicolon/comma/brace, the alignment of the subsequent comment will remain undisturbed. If RET puts the alignment out, you're cursing it. > > electric indentation is needed on keys other than RET; when that is the > > case, e-i on RET is superfluous. > Having RET in electric-indent-chars is not always indispensable, indeed. > But that doesn't make it harmful. And of course, if you want, you can > remove it from electric-indent-chars either in your .emacs or in c-mode. > >>>> But the global e-i-m setting is about deciding whether the user wants > >>>> his code to be automatically indented as he types (to the extent > >>>> possible). It is *defined* as a person-dependent preference. > >>> Clearly. I am pointing out that this definition is perhaps a suboptimal > >>> one. > >> I don't see what you mean by "definition" not "suboptimal" > > I think it's now clear which definition, your definition, we're talking > > about. > Thanks, yes, that makes sense. > > I put it to you, once more, that this "person-dependent" preference, > > as contrasted with a major-mode or buffer dependent one, > > is suboptimal. > What would be more optimal? A mode-dependent or buffer-local dependent setting, as well as, rather than instead of. > Clearly, having the major mode decide for the user is not better because > I can assure you that there are users who want electric indentation in > C-mode and there are others who don't. C Mode users who don't want electric indentation have been remarkably quiet about it on bug-cc-mode, at least since `c-toggle-electric-state' was introduced. Each major mode should be able to decide on its own default, which the user should be able to override easily. > > Minor modes which want to hook up their functionality to a key like "{" > > should do just that, not attempt to supersede other functionality. > > Mechanisms for this exist - electric-indent-mode uses one of these, for > > example. > Well, mechanisms to do that were added at the same time as > electric-indent-mode. Yes. > But so it seems the part of the design you dislike in > electric-indent-mode is not the use of post-self-insert-hook (as > I assumed) but something else. What is it? It is the conflation of electric indentation with the "-and-indent" part of `newline-and-indent', and the poor quality code this has led to. For example, `newline' and `newline-and-indent', strong, well understood, well coded functions have been superseeded by new `newline' and `electric-newline-and-maybe-indent', both vague functions which sometimes indent the new line, sometimes don't. Another example: `newline' has been sullied with a grotesque new parameter "interactive" whose meaning can not be reconciled with `newline''s functionality, but can only be described by a flowchart of new `newline''s internal workings. Having a minor mode tweek the global keymap on being enabled was grotesque, but that has, thankfully, now been fixed. The wierd implementation of `electric-indent-local-mode', which didn't work properly, is also getting fixed, though it is still needlessly complicated. I strongly dislike, even despise, the conflation of electric indentation with the way (RET C-j) are bound to (`newline' `newline-and-indent'). The bindings of these keys has nothing to do with electric indentation, and swapping their functionalities on {en,dis}abling e-i-m is bizarre. There was no discussion of this on emacs-devel, and no consensus for this change. What _was_ discussed was the swapping of the two bindings in programming modes, and it was coincidental that this discussion happened in an offshoot of a thread discussing electric indentation mode. Why can't we simply have RET bound to `newline-and-indent' and C-j bound to `newline' in programming modes, as discussed and, pretty much agreed on, in emacs-devel last autumn? Given that electric-indent-mode could have been implemented with the same functionality in a clear, straightforward fashion, it is galling to see the "clever", fragile, difficult to maintain code which we now have. None of this am I saying here for the first time. I object to the documentation of e-i-m on the info page "Convenience Functions", as though it were some minor convenience function rather than the essential component of automatic indentation it actually is. But I think we would agree this documentation needs amending anyway. > It seems now that your main (only?) objection is having RET do > reindent-then-newline-and-indent instead of having it only do > newline-and-indent. See above. ;-) > If that's the case, then let's focus on this. In what scenario is it a > problem? I suppose it's not really a big problem. Having RET/C-j as electric keys in CC Mode just isn't needed. _Any_ line of code in a real C/C++/... program is going to contain some other electric character. Other major modes would likely also benefit from having characters other than RET electric. Incidentally, in Emacs -Q, Text Mode and Fundamental Mode have gone back to the unwanted state of RET doing `newline-and-indent'. Should I raise another bug report? > Stefan -- Alan Mackenzie (Nuremberg, Germany).