Re: Electricity

["Andreas Röhler" <andreas.roehler@online.de>]

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
>
>