From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: John Yates Newsgroups: gmane.emacs.devel Subject: Re: Taming some chaos Date: Sat, 17 Oct 2015 11:16:02 -0400 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b67262cf03e4805224e6337 X-Trace: ger.gmane.org 1445094984 9307 80.91.229.3 (17 Oct 2015 15:16:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 17 Oct 2015 15:16:24 +0000 (UTC) To: Emacs developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 17 17:16:24 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZnTDZ-0001jO-VY for ged-emacs-devel@m.gmane.org; Sat, 17 Oct 2015 17:16:22 +0200 Original-Received: from localhost ([::1]:58622 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnTDY-0001GA-W9 for ged-emacs-devel@m.gmane.org; Sat, 17 Oct 2015 11:16:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35746) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnTDJ-0001G2-Jl for emacs-devel@gnu.org; Sat, 17 Oct 2015 11:16:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZnTDI-0006aE-74 for emacs-devel@gnu.org; Sat, 17 Oct 2015 11:16:05 -0400 Original-Received: from mail-pa0-x236.google.com ([2607:f8b0:400e:c03::236]:36433) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnTDI-0006a7-0d for emacs-devel@gnu.org; Sat, 17 Oct 2015 11:16:04 -0400 Original-Received: by pacfv9 with SMTP id fv9so50252229pac.3 for ; Sat, 17 Oct 2015 08:16:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=I2iAM/m2DMF2eKSs/JhNem2C1cbQjFyvILpkxIqnG+c=; b=WKzAecGIlk6CBZcxffaPwRnB8PDeFYT8RnXwOPP3mx/msHW50UBiC9dkf/MrzVDwWT yZypyp49h4lPgEnWrg+kuBWCJA8h/16gGQ2Exb4CJsZecwUBtjSsF/5IG+mntKFx60bx 35VgektPQ3nlmSuAXNKYcL4G3sGqXziT5E4QQ/NpmhszavkmhgvjH0y5m3ddHD7/2XCj l+FoE5mqSn5xSLMJlas1FOVb9E3g12YsZHwH9Tmf8JE4uv7cJa/Wgzy4W56Q2usAbMjo tEAi6G2vcHl3zdK/m5QdcFhI9E7zMAWXjY4VvfS3mNKHgN7mH24gTBKU+QEqtTaG/xi/ poaA== X-Received: by 10.68.98.34 with SMTP id ef2mr23537893pbb.45.1445094963031; Sat, 17 Oct 2015 08:16:03 -0700 (PDT) Original-Received: by 10.66.159.101 with HTTP; Sat, 17 Oct 2015 08:16:02 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: 00iK3IYOru4ldfNo9ZVEqWLnwxg X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400e:c03::236 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:191835 Archived-At: --047d7b67262cf03e4805224e6337 Content-Type: text/plain; charset=UTF-8 On Fri, Oct 16, 2015 at 7:20 PM, John Wiegley 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 --047d7b67262cf03e4805224e6337 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Oct 16, 2015 at 7:20 PM, John Wiegley <johnw@newartisans.com&g= t; 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 inf= lammatory.=C2=A0 At heart I am an
incrementalist.=C2=A0 It was ne= ver my intention to suggest tossing aside our
current code base a= nd package collection.

In leading projects I find = that my greatest successes have come when I
have been able to bri= dge an embraceable critique of the current state of
the system an= d an appealing vision of a future state with a credible set
of st= epping stones to get us there.=C2=A0 Since I have always worked in the
commercial space stepping stones have meant incremental deliverables<= /div>
that regularly added functionality or performance to a shipping p= roduct.

The Emacs community has long felt like a c= ollection of bright, polite
coders pursuing individual visions an= d scratching personal itches.=C2=A0 In
your postings to the ML it= seemed you were interested in stepping
forward to provide the le= adership needed to get us to rally to vision
of =C2=A0an enticing= Emacs future.=C2=A0 Articulating such a vision inherently
involv= es contrasting it with the current state of affairs.=C2=A0 I had hoped
that my note would be taken as a contribution to a discussion about
things could be improved.
=C2=A0
At this point, we can design new abstractions to be used by new code; but w= e
can't change how fundamental things are done

I could not agree more.=C2=A0 Dmitry responded: "Some higher abstraction
and UI=C2=A0would = do us some good. But it's not like it's trivial to even design
that." =C2=A0That is my = point.=C2=A0 To move forward in that dimension we need
some consensus that such changes are part of = where we want to go.
Once= =C2=A0such 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 personalitie= s of the old-timers in this community I have no
fear that Emacs will end up any less capable.=C2= =A0 It would be entirely in
character to provide new abstractions capable of being configured to
reproduce current=C2=A0behavior (probably the default for users= having yet
to register a= n specific choices).=C2=A0 A measure of success for any new
abstraction would be the=C2=A0rate at which actively maintained packages
would port over to using it= .

/= john

--047d7b67262cf03e4805224e6337--