From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?ISO-8859-1?Q?Andreas_R=F6hler?= Newsgroups: gmane.emacs.devel Subject: Re: Electricity Date: Fri, 08 Oct 2010 09:03:26 +0200 Message-ID: <4CAEC23E.6090407@online.de> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1286521473 19653 80.91.229.12 (8 Oct 2010 07:04:33 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 8 Oct 2010 07:04:33 +0000 (UTC) Cc: Stefan Monnier To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 08 09:04:32 2010 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.69) (envelope-from ) id 1P470J-0002s7-JQ for ged-emacs-devel@m.gmane.org; Fri, 08 Oct 2010 09:04:31 +0200 Original-Received: from localhost ([127.0.0.1]:45308 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P470I-0004UC-07 for ged-emacs-devel@m.gmane.org; Fri, 08 Oct 2010 03:04:30 -0400 Original-Received: from [140.186.70.92] (port=59327 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P46zz-0004U5-Vk for emacs-devel@gnu.org; Fri, 08 Oct 2010 03:04:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P46zy-0004VJ-IN for emacs-devel@gnu.org; Fri, 08 Oct 2010 03:04:11 -0400 Original-Received: from moutng.kundenserver.de ([212.227.17.8]:65072) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P46zy-0004VE-7K for emacs-devel@gnu.org; Fri, 08 Oct 2010 03:04:10 -0400 Original-Received: from noname.home (brln-4dbc5dd9.pool.mediaWays.net [77.188.93.217]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0McyCA-1PL5cK3BsQ-00Hlrj; Fri, 08 Oct 2010 09:04:08 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 In-Reply-To: X-Provags-ID: V02:K0:Bc7RY7oF6Qb5cQMb1wrv2+Aq8XMVQL8SdS+HjaxGrr+ +saKbxgIkseP6NPby4vqKDHkteDzCT26tSmughjD5JTnwJCOWh D2gfY6+UjQauHv40kjs9uy2AiGWivCdSe80Q4A74bmiByd0hJ3 NWr+7wQps+8Cp5G2Aidvj3d2GNU8uCWY6eLb5XqQZsBPlwfEmN 0bFFiltyjCuRI0FsJjwSn4bgZGFtALq+PCqzrjNERQ= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. 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:131471 Archived-At: Am 07.10.2010 12:36, schrieb Stefan Monnier: > For Emacs-24, one of the things I'd like to clean up is the "electric > key" mess. Currently each and every major mode does it its own way, > making it difficult for users to enable/disable it. I'd like to provide > a generic infrastructure for such features, such that major modes can > provide it in a standard way, and so that users can enable/disable it > globally rather than mode-by-mode. > Great. That's the kind of approach Emacs may be easier to use as to extend IMHO. Let me mention the issue of return values. Related kinds of Emacs commands/functions should have the same kind of return value and user options. It should be enough reading the doku of one function to make correct expections concerning the related ones. Precisely: if pairs of parentheses, braces, bracketes are inserted, propose it's positions as return values, delivered as a cons. Also messaging that cons/conses if interactively called. Writing cons/conses as this could be perceived as delimiters, where ml-languages come with larger ones. BTW just reading a little bit around Scrum and related project management tools. Got the impression, Emacs may profit from it. Not that much from the sprint part, but from formular utilities, which allow tracking items and ranging them during a long time. Mailing lists tend to forget and bug trackers too, as they lack the hierarchical sorting of tasks resp. have only poor implementation of it. Also lists and pure trackers lacks the space to collect abstract reflections over a time, correcting it at place, refining it etc. Maybe org-mode already provides everything needed? Andreas -- https://code.launchpad.net/~a-roehler/python-mode/python-mode-components https://code.launchpad.net/s-x-emacs-werkstatt/ > I've recently added electric-indent-mode (as well as electric-pair-mode) > as a first step in that direction. > > So there are two things left to do here: > > - the main one: add support for electric-indent-mode to major modes (it > can mean just to add a buffer-local setting for electric-indent-chars, > but it may also mean to somehow disable the pre-existing ad-hoc > electric-key code). > > I'm OK with breaking user-compatibility in the sense that I think > major modes should not enable electric-indent-mode themselves, which > means that modes that currently make some keys electric by default > may see their behavior changed (depending on the default chosen for > electric-indent-mode ;-) > > - look for remaining forms of electric-keys and try and provide generic > support for it (the addition/removal of newlines around special chars > like { in C is one such example). > > Patches welcome, > > > Stefan > >