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, 16 Mar 2014 22:35:09 +0000 Message-ID: <20140316223509.GD3854@acm.acm> References: <20140222182704.GA2639@acm.acm> <20140228195051.GA3446@acm.acm> <20140302115118.GA3768@acm.acm> <20140308225820.GB2726@acm.acm> <20140309123711.GA2615@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1395009538 8505 80.91.229.3 (16 Mar 2014 22:38:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 16 Mar 2014 22:38:58 +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 16 23:39:07 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 1WPJhy-0006BK-5d for ged-emacs-devel@m.gmane.org; Sun, 16 Mar 2014 23:39:06 +0100 Original-Received: from localhost ([::1]:54811 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WPJhx-0007tX-Nb for ged-emacs-devel@m.gmane.org; Sun, 16 Mar 2014 18:39:05 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50420) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WPJhn-0007sR-1x for emacs-devel@gnu.org; Sun, 16 Mar 2014 18:39:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WPJhf-0003MV-Ia for emacs-devel@gnu.org; Sun, 16 Mar 2014 18:38:54 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:33297 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WPJhf-0003LP-9G for emacs-devel@gnu.org; Sun, 16 Mar 2014 18:38:47 -0400 Original-Received: (qmail 89636 invoked by uid 3782); 16 Mar 2014 22:38:45 -0000 Original-Received: from acm.muc.de (pD9519ECD.dip0.t-ipconnect.de [217.81.158.205]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 16 Mar 2014 23:38:44 +0100 Original-Received: (qmail 5097 invoked by uid 1000); 16 Mar 2014 22:35:09 -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:170426 Archived-At: Hi, Stefan. On Sun, Mar 09, 2014 at 11:37:36PM -0400, Stefan Monnier wrote: > >> What is essential for me is that C-mode have the same behavior as other > >> modes. I.e. obey electric-indent-mode. > > Major modes provide different behaviours, behaviours appropriate to the > > type of text being edited. That's why we have major modes. > Right. But I don't see what is so special about the C language that > makes c-electric-flag (aka electric-indent-mode) indispensable in c-mode. CC Mode modes don't indent correctly automatically without electric indentation. This is in the typical case where lines of code are being typed in, line by line. > Better don't bother answering: electric-indent-mode is enabled by > default anyway, so there's really no problem here. Good! > The question is really: why do you need to know if electric-indent-mode > was called (and even how many times)? From what I understand of your > previous answers it is because you want to only obey > electric-indent-mode if the user changed the default. Not quite. I want the default for CC Mode modes to be t, regardless of any system wide default. I think it likely there will be other major modes which need a default of nil. Once a user has positively indicated which way she wants the setting, then that is fine. > If so, what is wrong about testing Emacs's version instead? ???? > AFAIK your only worry is when electric-indent-mode is nil to make sure > that the user really meant it. But if you test Emacs's version to make > sure it's >24.3, then electric-indent-mode can only be nil if the user > decided so. electric-indent-mode is, essentially, new code, and its default doesn't appear yet to have stabilised. As I've already said, I anticipate a storm of protest and a sea of confusion over this new default. In order to quell the protest, there will be the option of making the default nil in future versions. It would be good to have CC Mode decoupled from this. > So you don't need to know if electric-indent-mode has been called nor > how many times. > Stefan > > > No, we should only care about "enabled" and "disabled". > > That's a fairly contentious opinion, not backed up by any reasoning. > > Would you care to give your reasons why "default state" is not to be > > cared about? > You know very well: > some major modes have historically setup some keys to electrically > reindent the current line. And some haven't. This just reflects > the personal preference of the major mode's author(s). No. It reflects the intrinsic needs of the major mode. CC Mode needs it, Emacs Lisp Mode is never going to have a use for it, Text Mode needs it nil, and in some modes, electric indentation plain doesn't work (python, for example). > It also means that a user who doesn't like this behavior needs to > disable it separately for each and every such major mode (which > includes figuring out how to disable it, which is not standardized > either). And it also means that a user who does like this behavior > will have to tweak the other major modes. I think you are wrong in your tacit assumption that liking of e-i-m is person dependent rather than major mode dependent. > Hence my introducing electric-indent-mode to standardize the behavior > across modes. As is too often the case, CC-mode is the only one that > doesn't want to get in line. The way electric-indent-mode was implemented seems optimised to maximise the difficulty of integrating CC Mode with it. My main concern over this integration has been avoiding loss of or damage to functionality. CC Mode's electric indentation is essentially 100% perfect, all the rough edges and conflicts having been debated and settled in long forgotten 20 year old exchanges. Have you ever wondered why RET and C-j aren't electric keys in CC Mode? Compatibility with stand-alone CC Mode has also been of some concern. > > As we have discussed before, it is essential that c-electric-flag be > > enabled by default for CC Mode buffers. Without it, indentation would > > need to be done manually, e.g. by continual use of the tab key. > Right: when electric-indent-mode is nil, it means that the user wants to > have control over when auto-indentation is performed. That's not a bug. This is the case after e-i-m has been SET to nil. What is a bug (IMNSHO) is that this selection is not buffer local. Other similar features are implemented as buffer local with a "global-*" variant: font-lock-mode, hi-lock-mode, ..... There are at least 17 such minor modes with a global variant. electric-indent-mode is going to be inconsistent with these other modes. Why couldn't we have had electric-indent-mode and global-electric-indent-mode? > On the contrary: it is crucial to stay sane when you're editing code > using an indentation convention that's different from the one supported > by the major mode. That is indeed the use case for no electric indentation (with the lesser one of newbies who can't yet cope with it). > But indeed, electric-indent-mode is enabled by default, because we > recognize that it is overall better to try and maintain indentation > without forcing the user to constantly use TAB. Yes. > > Yet c-electric-flag, a buffer local flag, is now inextricably coupled > > to electric-indent-mode, a crude global flag. A user wishing to > > disable electric-indent-mode for some random buffer will find > > automatic indentation broken in her C Mode buffers. > No, she will find it correctly disabled, according to her wish expressed > by the fact that she disabled electric-indent-mode. You're assuming here that she will be disabling e-i-m due to a general dislike of electricity, rather than having an isolated chaotically indented buffer. > > There is no mechanism provided to users by electric-indent-mode to enable > > it selectively in a buffer. > Alan, please be constructive: you know full well this is untrue. > > Even the undocumented electric-indent-local-mode > The fact that it's not yet documented is irrelevant, since that's > a problem that needs to be addressed anyway (and rather sooner than > later since it's one of the hurdles remaining for the trunk to re-open). :-) > > doesn't work properly, as you admitted recently. > Right, it has some bugs open, and we'll have to fix them for 24.4. Double :-). On 2014-02-18 you opined "I don't think it's worth the trouble" to fix. I feel relieved it will be getting fixed now. > > In the massive confusion and possible protest that will follow in the > > wake of the release of electric-indent-mode, one of your options will be > > to disable the mode by default. > Come on, Alan. You know me better than that. > And FWIW you've been the strongest voice *against* enabling > electric-indent-mode, oddly enough. I don't think so. I have strongly objected to the design features of electric-indent-mode and protested against the collateral effects they have on the rest of Emacs. > > Would you please give your word, as a gentleman, that whatever > > transpires, after the sequence emacs -Q, C-x C-f foo.c, foo.c's copy > > of c-electric-flag will always be t. > No, I can't, sorry: if it were up to me, c-electric-flag would not even > exist any more. Yes, I'm sure. The flag is needed for all Emacsen which aren't GNU Emacs 24.4+. It is well tested, works, seems to be used, and has never elicited complaints from users. > But I can give you my word that "automatic indentation as a side effect > of normal editing" will be enabled by default in programming modes, > including C-like modes, yes. Thanks. That will do. > Stefan -- Alan Mackenzie (Nuremberg, Germany).