From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Electric indentation (Was: Re: js.el changes) Date: Fri, 21 Aug 2009 12:35:44 -0400 Organization: Merrill Print Message-ID: <200908211235.44988.danc@merrillprint.com> References: <87y6plkhj6.fsf@stupidchicken.com> <200908211228.17606.danc@merrillprint.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1250872568 637 80.91.229.12 (21 Aug 2009 16:36:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 21 Aug 2009 16:36:08 +0000 (UTC) Cc: emacs-devel@gnu.org To: Lennart Borgman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 21 18:36:01 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MeX5s-0000o2-2z for ged-emacs-devel@m.gmane.org; Fri, 21 Aug 2009 18:36:00 +0200 Original-Received: from localhost ([127.0.0.1]:48620 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MeX5r-00045W-Dw for ged-emacs-devel@m.gmane.org; Fri, 21 Aug 2009 12:35:59 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MeX5m-00045R-CB for emacs-devel@gnu.org; Fri, 21 Aug 2009 12:35:54 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MeX5h-0003zW-AY for emacs-devel@gnu.org; Fri, 21 Aug 2009 12:35:53 -0400 Original-Received: from [199.232.76.173] (port=58291 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MeX5h-0003zK-3n for emacs-devel@gnu.org; Fri, 21 Aug 2009 12:35:49 -0400 Original-Received: from vpn.merrillpress.com ([64.61.107.78]:48874) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MeX5g-0004CF-Eo for emacs-devel@gnu.org; Fri, 21 Aug 2009 12:35:48 -0400 Original-Received: from pluto.merrillpress.net ([10.136.5.5] helo=pluto.localnet) by mars.merrillpress.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1MeX5d-00013r-TA; Fri, 21 Aug 2009 12:35:45 -0400 User-Agent: KMail/1.11.4 (Linux/2.6.29.6-217.2.8.fc11.i586; KDE/4.2.4; i686; ; ) In-Reply-To: X-Face: 9VC; >}hM+`K4j{H4n=pq/!61'7Rt"vEaPUdCwpS'=; @B7Ll,~Q.xb(|A>; 8M[\UzKQi{>Q Iptc6NY\M(0<{W?ob}e/91Y!k|XE:2SA2LU"cni>#Dmw4siEWG7|L9zkOZ\[nQPe9[PG|s P2n_jW\TzsG2N1Z0q:E#NmWU~0i]JE)gqB|4{jCjolaX6)KO[@k\:>01.58.Pk5Nb\5s": R,Q78_s; 6+vLj\V1y(`]\G3("(Y!G^79x}q[4L8w[.qEs|+ZN0R`Hk,>y; d7!SFx%M2M39 y[/Kc!p!:.E3Zx')v*l6IlR Content-Disposition: inline X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:114480 Archived-At: On Friday 21 August 2009, you wrote: > On Fri, Aug 21, 2009 at 6:28 PM, Daniel Colascione wrote: > > On Friday 21 August 2009, you wrote: > >> Maybe it could be done similar to indent-line-function etc? > > > > Err, how do you mean? Different electric keys require different behavior in different modes. One variable can't be used to dispatch to all these various pieces of code. You could have electric-indentation-mode call a mode-specific function that decides what to do with a given electric key, but isn't that just reimplementating the keymap mechanism? > > > It allows you to have a minor mode to toggle the behaviour. I feel like we're talking past each other. Right now, a mode like js-mode or cc-mode binds keys that are supposed to be electric to a mode-specific function. Let's use cc-mode as an example: it binds { to c-electric-brace. c-electric-brace runs self-insert-command and checks whether the variable c-electric-flag is true. If it is, it performs some specific indentation operations. My proposal is to create a new globalized minor mode called electric-indentation-mode. An electric insert function like c-electric-brace, instead of checking a mode-specific flag, would instead check the value of the variable electric-indentation-mode. That way, the user can use one interface to enable or disable electric indentation for all supported modes at once.