Re: In defense of Customize [was: Trying to right-align my window on startup]

[Rusi <rustompmody@gmail.com>]

On Thursday, January 30, 2014 6:53:07 PM UTC+5:30, Stefan Monnier wrote:
> FWIW, I agree to a large extent with Christoph's criticism.

> I'd be happy to see improvement in this area.

> I think a good way to improve this area is to work on making it easier
> to write Elisp customizations.  E.g. provide new functions/macros to make
> the most common kinds of customization easier.

> I guess that would mean things like "function to change a key-binding in
> major mode foo" where that function takes care of delaying the
> key-binding until that time where the major mode's map is
> actually defined.  Part of the difficulty is to make these things "clean
> and robust".

Some stray thoughts:

1. emacs is an OS
2. elisp is an imperative language

Well 1 is not true in a literal sense but its close enough

Now one of the issues in OS management is startup/daemons.

Even good old init had a way of ordering the startup scripts by prefixing
numbers.  But this was far from enough and so people are coming up with
more declarative approaches like ubuntu's upstart

See this, particularly the use-cases
https://wiki.ubuntu.com/ReplacementInit

The idea is that once some events are identified, the start/stop of services
is setup based on invariants of events rather than by explicit micro-sequencing.

Brings me to the next point -- elisp is too sequential/imperative

Of late many of my elisp problems have this flavour:
I share some parts of my init with some co-workers and things fall apart
because of some require missing or some wrong misplaced loaddefs etc.

I believe that customize as it exists cannot solve this because the
level at which it is written is too high.  As a result the imperative
underbelly of lisp keeps showing through