From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier 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 12:46:10 -0400 Message-ID: References: <20140319224231.GB4783@acm.acm> <20140322131350.GA3163@acm.acm> <20140322223454.GA3562@acm.acm> <20140324224055.GB3825@acm.acm> <20140326212117.GB3787@acm.acm> <20140330113750.GA3338@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1396198001 9013 80.91.229.3 (30 Mar 2014 16:46:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 30 Mar 2014 16:46:41 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 30 18:46:34 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 1WUIsS-000337-Aa for ged-emacs-devel@m.gmane.org; Sun, 30 Mar 2014 18:46:32 +0200 Original-Received: from localhost ([::1]:44950 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WUIsR-0004nZ-Pu for ged-emacs-devel@m.gmane.org; Sun, 30 Mar 2014 12:46:31 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52257) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WUIsH-0004nQ-La for emacs-devel@gnu.org; Sun, 30 Mar 2014 12:46:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WUIsA-0002CE-5O for emacs-devel@gnu.org; Sun, 30 Mar 2014 12:46:21 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:58665) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WUIs9-0002Bz-Uy for emacs-devel@gnu.org; Sun, 30 Mar 2014 12:46:14 -0400 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id s2UGkAjv010902; Sun, 30 Mar 2014 12:46:10 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 31D016013A; Sun, 30 Mar 2014 12:46:10 -0400 (EDT) In-Reply-To: <20140330113750.GA3338@acm.acm> (Alan Mackenzie's message of "Sun, 30 Mar 2014 11:37:50 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0.2 X-NAI-Spam-Rules: 2 Rules triggered SUBJ_END_HASH_PTRN=0.2, RV4897=0 X-NAI-Spam-Version: 2.3.0.9362 : core <4897> : inlines <663> : streams <1147821> : uri <1714973> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 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:171203 Archived-At: >> >> 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. This is a non-starter: cutting the link between the two is not really up for negotiation, it's an important part of keeping the interface simple. That is: it's OK to have a custom var deciding whether e-i-m swaps RET and LF, but by default that custom var should be enabled. > Eh? How does global-font-lock-mode, for example, not work 100%? Analyze the code from a suspicious point of view, like you do for e-i-m, and you'll soon find ways. Or use your memory of problems we've had. >> 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. I'd be very surprised if it doesn't change functionality: saying it doesn't is not sufficient. Stefan