unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Electricity
@ 2010-10-07 10:36 Stefan Monnier
  2010-10-08  7:03 ` Electricity Andreas Röhler
  0 siblings, 1 reply; 2+ messages in thread
From: Stefan Monnier @ 2010-10-07 10:36 UTC (permalink / raw)
  To: emacs-devel

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.

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



^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Electricity
  2010-10-07 10:36 Electricity Stefan Monnier
@ 2010-10-08  7:03 ` Andreas Röhler
  0 siblings, 0 replies; 2+ messages in thread
From: Andreas Röhler @ 2010-10-08  7:03 UTC (permalink / raw)
  To: emacs-devel; +Cc: Stefan Monnier

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




^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2010-10-08  7:03 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-10-07 10:36 Electricity Stefan Monnier
2010-10-08  7:03 ` Electricity Andreas Röhler

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).