From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan 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 12:14:54 -0400 Message-ID: References: <20140302115118.GA3768@acm.acm> <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 X-Trace: ger.gmane.org 1395504904 30316 80.91.229.3 (22 Mar 2014 16:15:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 22 Mar 2014 16:15:04 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 22 17:15:13 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 1WROZl-0000RN-A8 for ged-emacs-devel@m.gmane.org; Sat, 22 Mar 2014 17:15:13 +0100 Original-Received: from localhost ([::1]:57583 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WROZk-0000Hn-PG for ged-emacs-devel@m.gmane.org; Sat, 22 Mar 2014 12:15:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52118) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WROZa-0000C7-S3 for emacs-devel@gnu.org; Sat, 22 Mar 2014 12:15:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WROZT-0000ZL-GR for emacs-devel@gnu.org; Sat, 22 Mar 2014 12:15:02 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:47155) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WROZT-0000ZG-BU for emacs-devel@gnu.org; Sat, 22 Mar 2014 12:14:55 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFHAqyMT/2dsb2JhbABEvw4Xc4IeAQEEAVYWDQULCw4mEhQYDSSIHgbBLZEKA44YmECDEw X-IPAS-Result: Av4EABK/CFHAqyMT/2dsb2JhbABEvw4Xc4IeAQEEAVYWDQULCw4mEhQYDSSIHgbBLZEKA44YmECDEw X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="52973318" Original-Received: from 192-171-35-19.cpe.pppoe.ca (HELO pastel.home) ([192.171.35.19]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 22 Mar 2014 12:14:54 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 51E45600A9; Sat, 22 Mar 2014 12:14:54 -0400 (EDT) In-Reply-To: <20140322131350.GA3163@acm.acm> (Alan Mackenzie's message of "Sat, 22 Mar 2014 13:13:50 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:170808 Archived-At: >> 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 have no idea what you're talking about. "electric-indent" to me means "try to keep code indented without having to hit TAB". 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. > 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. > 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. > 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. >> >> 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. To me, the algorithm used by haskell-mode could not be used in another context, so this distinction makes no sense. > You've cut out the necessary context again, and put me to unnecessary > work to restore it. No, it's because the context did not manage to explain to me the text that I quoted. I stripped this context because it was not useful for me to explain precisely which part I failed to understand. > 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. 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? 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. > 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. 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 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. If that's the case, then let's focus on this. In what scenario is it a problem? Stefan