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 13:13:50 +0000 Message-ID: <20140322131350.GA3163@acm.acm> References: <20140302115118.GA3768@acm.acm> <20140308225820.GB2726@acm.acm> <20140309123711.GA2615@acm.acm> <20140316223509.GD3854@acm.acm> <20140319224231.GB4783@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1395494273 17628 80.91.229.3 (22 Mar 2014 13:17:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 22 Mar 2014 13:17:53 +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 14:18:01 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 1WRLoH-0003Cv-5W for ged-emacs-devel@m.gmane.org; Sat, 22 Mar 2014 14:18:01 +0100 Original-Received: from localhost ([::1]:56964 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WRLoG-0004Tt-NZ for ged-emacs-devel@m.gmane.org; Sat, 22 Mar 2014 09:18:00 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36219) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WRLo5-0004RF-DY for emacs-devel@gnu.org; Sat, 22 Mar 2014 09:17:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WRLnw-0000ty-Bd for emacs-devel@gnu.org; Sat, 22 Mar 2014 09:17:49 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:63478 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WRLnv-0000tN-VP for emacs-devel@gnu.org; Sat, 22 Mar 2014 09:17:40 -0400 Original-Received: (qmail 87906 invoked by uid 3782); 22 Mar 2014 13:17:37 -0000 Original-Received: from acm.muc.de (pD951ACD2.dip0.t-ipconnect.de [217.81.172.210]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 22 Mar 2014 14:17:36 +0100 Original-Received: (qmail 4109 invoked by uid 1000); 22 Mar 2014 13:13:50 -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:170790 Archived-At: Hello, Stefan. On Wed, Mar 19, 2014 at 09:46:03PM -0400, Stefan wrote: > >> And the same holds true for all other programming modes. > > No it doesn't. We both agree that Emacs Lisp Mode has no use whatsoever > > for electric indentation. > No, I don't agree. First because most people don't use C-j but use > RET instead, and second because typing text linearly is far from being > the only important editing pattern. ???? That's a non-sequitur. 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 suggest you think hard about the disadvantages of RET as an > > electric indentation key. If there weren't such disadvantages, CC Mode > > would have been using it for 20 years. > I need your help here, I'm afraid. And I'm obviously not the only, > because it's very common for text editors to "auto-indent on RET" > (either by default, or via a config setting). You're being vague, here. By "auto-indent on RET" you could mean indent the existing line ("electric indentation") or the new line created ("newline-and-indent"). The newline-and-indent behaviour is common in other editors, electric indentation is not. (I'm not aware of another editor which does it, but I'm willing to be informed of any.) Using electric indentation on RET is poor, because it only works when you actually type a RET (or a C-j). 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. If you are typing in comments at the end of code lines, you won't want electric indentation messing up their alignment. You also want to know how much space you've got between the comment opener and "column 80", for whatever value of column 80 you use. You will want electric indentation to have done its thing _before_ you start typing the comment. Thus electric indentation is needed on keys other than RET; when that is the case, e-i on RET is superfluous. > >> There are details about *how* e-i-m works which depend on the mode. > >> Yes. That's why e-i-m has mode-local settings (e.g. which keys are > >> electric, or whether the indentation algorithm can reliably reindent). > > Any "indentation algorithm" can reliably reindent. It is the context > > in which the algorithm is used which is important, not the algorithm > > itself. > No: python-mode, haskell-mode, and coffeescript-mode can't. We're in violent agreement, here. It is the context (i.e. the major mode) these indentation algorithms are used in, not the algorithms themselves. The algorithms themselves are perfectly capable of reindentation. > > Clearly. I am pointing out that this definition is perhaps a suboptimal > > one. > I don't see what you mean by "definition" not "suboptimal". You've cut out the necessary context again, and put me to unnecessary work to restore it. This makes it look like you want to evade answering the point, without being obvious that this is what you are doing. This is one of the most irritating tactics that can be used on a mailing list, short of out and out trolling. PLEASE STOP DOING THIS!!!! Here is that context, restored: >>> 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. I put it to you, once more, that this "person-dependent" preference, as contrasted with a major-mode or buffer dependent one, is suboptimal. > > Not even that. You were in so much of a hurry to reinvent the wheel, > > that you were oblivious of perfectly round wheels with smooth bearings > > which had been in existence for ~20 years. > No, I know those wheels very well, because I suffered through many of > them. Your "suffering", outlined below, concerned a peripheral annoyance, not the basic design. If that suffering was so great, how come you never sent a report to bug-cc-mode about it? The point is, that you could easily have taken over the design features of CC Mode's electric indentation, which would likely have gone through all sorts of false starts and design mistakes 20 years ago before emerging with its well considered, slick design. Instead, you started from scratch, repeating history instead of learning from it. > The problem is they're not modular: your rebinding of ?{ to make it > auto-indent means that my global binding of ?{ to make it auto-pair > doesn't work in c-mode. You're saying it's OK for a _MINOR_ mode to bind "{" ??? This is crazy. Supposing another minor mode also wanted to bind "{" for its purposes? Which one wins? This is clearly unsustainable. 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. > Stefan -- Alan Mackenzie (Nuremberg, Germany).