emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Electricity


From: Andreas Röhler
Subject: Re: Electricity
Date: Fri, 08 Oct 2010 09:03:26 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6

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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]