On Fri, Oct 16, 2015 at 7:20 PM, John Wiegley <johnw@newartisans.com> wrote:

> However, I think that ship has sailed. The changes you propose in your
> message
> would require a ground-up redesign of many aspects of Emacs, would they
> not?
> We have so much extant Emacs Lisp code, and lot of Emacs' value lies in
> that
> code, and not merely in its fundamentals.
>

John,

I fear my opening paragraphs were too inflammatory.  At heart I am an
incrementalist.  It was never my intention to suggest tossing aside our
current code base and package collection.

In leading projects I find that my greatest successes have come when I
have been able to bridge an embraceable critique of the current state of
the system and an appealing vision of a future state with a credible set
of stepping stones to get us there.  Since I have always worked in the
commercial space stepping stones have meant incremental deliverables
that regularly added functionality or performance to a shipping product.

The Emacs community has long felt like a collection of bright, polite
coders pursuing individual visions and scratching personal itches.  In
your postings to the ML it seemed you were interested in stepping
forward to provide the leadership needed to get us to rally to vision
of  an enticing Emacs future.  Articulating such a vision inherently
involves contrasting it with the current state of affairs.  I had hoped
that my note would be taken as a contribution to a discussion about
things could be improved.


> At this point, we can design new abstractions to be used by new code; but
> we
> can't change how fundamental things are done


I could not agree more.  Dmitry responded: "Some higher abstraction
and UI would do us some good. But it's not like it's trivial to even design
that."  That is my point.  To move forward in that dimension we need
some consensus that such changes are part of where we want to go.
Once such consensus emerges I have no doubt that design discussions
would arise naturally.

... in a way that suddenly makes
> Emacs far less capable by breaking reams of existing code.
>

Given the personalities of the old-timers in this community I have no
fear that Emacs will end up any less capable.  It would be entirely in
character to provide new abstractions capable of being configured to
reproduce current behavior (probably the default for users having yet
to register an specific choices).  A measure of success for any new
abstraction would be the rate at which actively maintained packages
would port over to using it.

/john