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: Sun, 30 Mar 2014 11:37:50 +0000 Message-ID: <20140330113750.GA3338@acm.acm> References: <20140319224231.GB4783@acm.acm> <20140322131350.GA3163@acm.acm> <20140322223454.GA3562@acm.acm> <20140324224055.GB3825@acm.acm> <20140326212117.GB3787@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1396179734 28849 80.91.229.3 (30 Mar 2014 11:42:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 30 Mar 2014 11:42:14 +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 Mar 30 13:42:06 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 1WUE7p-0004ru-Te for ged-emacs-devel@m.gmane.org; Sun, 30 Mar 2014 13:42:06 +0200 Original-Received: from localhost ([::1]:43903 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WUE7p-000432-7U for ged-emacs-devel@m.gmane.org; Sun, 30 Mar 2014 07:42:05 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39580) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WUE7e-00040x-Ve for emacs-devel@gnu.org; Sun, 30 Mar 2014 07:42:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WUE7V-0006iV-JH for emacs-devel@gnu.org; Sun, 30 Mar 2014 07:41:54 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:40666 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WUE7V-0006he-9Q for emacs-devel@gnu.org; Sun, 30 Mar 2014 07:41:45 -0400 Original-Received: (qmail 5501 invoked by uid 3782); 30 Mar 2014 11:41:42 -0000 Original-Received: from acm.muc.de (pD951BAC8.dip0.t-ipconnect.de [217.81.186.200]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 30 Mar 2014 13:41:41 +0200 Original-Received: (qmail 3509 invoked by uid 1000); 30 Mar 2014 11:37: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:171194 Archived-At: Hello, Stefan. On Thu, Mar 27, 2014 at 10:49:06AM -0400, Stefan Monnier wrote: > >> I want to keep electric-indent-mode as a global mode that determines > >> whether certain self-inserting keys (such as RET and others) auto-indent. > > How is this not satisfied by e-i-m being a define-globalized-minor-mode? > AFAICT your suggestion would not swap RET/C-j depending on e-i-m. It would most emphatically not do so. That is something which was never discussed on emacs-devel before it was implemented, and it is wrong. Unrelated things should not be bound together into a single action. > > With the current setup, we have a rather contorted relationship between > > e-i-m and e-i-local-m, with buffer local copies of electric-indent-mode > > popping into and out of existence. > For a setting which is mostly global by nature (it reflects on the > user's general preference), I'm not worried and generally prefer this > over using define-globalized-minor-mode which is a fine hack, but > a hack nevertheless. Eh? How does global-font-lock-mode, for example, not work 100%? It is also "mostly global by nature". What might not work properly if e-i-m was made into a globalized minor mode? With a globalized-minor-mode, it is predictable which buffers are affected when the global command is given, namely all of them. With e-i-m, only some buffers are affected, and there is currently no rationale behind which ones are, which ones aren't. You need to read the source code to work this out, and that is bad. > > What about the rest of my suggestion? > I'm worried about the possible consequences: e-i-m has been around for > a little while now and we're somewhat familiar with its problems. The changes I'm proposing, with the exception already noted, are not changes in functionality. e-i-m is essentially still fresh code - one or two enthusiasts used it in 24.3, but it hasn't really hit big time yet. Now is the right time to sort out its problems. Besides, we're hackers, and we're competent. :-) > Your approach might solve some problems (tho I haven't seen a clear > statement of what those problems are, in terms of *behavior*), ... e-i-m also toggling RET/C-j is a behaviour problem, as noted above. But the other problems are those of bad design and bad coding, not bad behaviour. They are all the the consequence of a single design mistake, namely that e-i-post-self-insert-function tries to handle the indentation of a new line. This has led to difficult to understand overcomplicated coding, functional duplication, disassociation of functionality from defuns, damaged backward compatibility, .... These problems should be _fixed_. To fix them is not difficult. I'm willing to do this. > .... but will inevitably come with its own set of consequences. Inevitably? How so? > Stefan -- Alan Mackenzie (Nuremberg, Germany).