Re: Taming some chaos

[John Yates]

On Fri, Oct 16, 2015 at 7:20 PM, John Wiegley <address@hidden> 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