From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jeremy Bryant Newsgroups: gmane.emacs.devel Subject: Re: Emacs Survey: Toolbars Date: Thu, 25 Feb 2021 22:53:02 +0000 Message-ID: <878s7bg3ox.fsf@jeremybryant.net> References: <87o8iv3ac3.fsf@gnus.org> <877dpjp30g.fsf@ucl.ac.uk> <87zh2fnmwq.fsf@gnus.org> <87o8ivumn5.fsf@telefonica.net> <87v9d3nkxk.fsf@gnus.org> <83ft3zrtgy.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6128"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.4.15; emacs 28.0.50 Cc: dimech@gmx.com, abrochard@gmx.com, rms@gnu.org, bugs@gnu.support, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Feb 25 23:54:42 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lFPWs-0001U8-AQ for ged-emacs-devel@m.gmane-mx.org; Thu, 25 Feb 2021 23:54:42 +0100 Original-Received: from localhost ([::1]:50500 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lFPWr-0003K2-Bh for ged-emacs-devel@m.gmane-mx.org; Thu, 25 Feb 2021 17:54:41 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57442) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lFPVR-0002bL-MX for emacs-devel@gnu.org; Thu, 25 Feb 2021 17:53:13 -0500 Original-Received: from mailex.mailcore.me ([94.136.40.145]:34322) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lFPVP-00027F-51; Thu, 25 Feb 2021 17:53:13 -0500 Original-Received: from [188.214.8.247] (helo=hexa2.local.com) by smtp02.mailcore.me with esmtpa (Exim 4.92.3) (envelope-from ) id 1lFPVJ-0008X0-Bx; Thu, 25 Feb 2021 22:53:06 +0000 In-reply-to: <83ft3zrtgy.fsf@gnu.org> X-Mailcore-Auth: 278589627 X-Mailcore-Domain: 1689493 Received-SPF: none client-ip=94.136.40.145; envelope-from=jb@jeremybryant.net; helo=mailex.mailcore.me X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:265654 Archived-At: In the spirit of this discussion on the merits and possibility of planning (or not), there is an interesting quote below. I found it useful for thinking about the special characteristics of Emacs, and perhaps others on this list will find it interesting to consider. attributed (in the Free as in Freedom book)to RMS from a 1979 AI Lab memo EMACS could not have been reached by a process of careful design, because = such processes arrive only at goals which are visible at the outset, and whose desirability is established on the bottom line at the outset. Neither I nor anyone else visualized an extensible editor until I had made one, nor appreciated its value until he had experienced it. EMACS exists because I = felt free to make individually useful small improvements on a path whose end wa= s not in sight. Although I couldn't locate the original source of exact quote, there is a l= onger piece from the 1979 memo from RMS on the same subject. Implications for the Process of System Design=20 It is generally accepted that when a program is to be written, specificatio= ns=20 should be designed in advance. If this is not done, the result will be infe= rior.=20 Some people know better than this, but none dare to speak up.=20 The writing of EMACS was as far from along these lines as can be imagined. = It=20 is best thought of as a continuous deformation of TECO into something which= ,=20 for users, has no resemblance to TECO.=20 And indeed, there are ways in which EMACS shows the results of not having=20 been completely thought out in advance, if only in being based on TECO rath= er=20 than Lisp. (Nevertheless, EMACS has shown itself to be reliable and suitabl= e for=20 widespread use). If EMACS hadTbeen specified in advance, it would resemble= =20 the post-EMACS editors described above. However, the post-EMACS editors=20 were specified in advance by EMACS itself, and could not have been written = if=20 not preceded by EMACS (this is not to say that they have copied slavishly; = they=20 have continued the process of gradual development). And EMACS could never=20 have' been arrived at except in the way it actually was. The chain of neces= sary=20 steps leading to EMACS, starting with the display processor, was simply too= long=20 for anyone to have imagined the final result before the first step had been= taken.=20 If we had insisted on moving only toward destinations visible at the beginn= ing,=20 we would never have got here from there!=20 This is true of all the details of the individual commands as well as of th= e=20 structure of the system. Each command in EMACS behaves as it does as a=20 result of experimentation by many different users customizing their editors= in=20 =C2=A3 MACS June 22, 1979=20 21=20 MIT Al Lab=20 different ways, in the years when the display processor existed but EMACS h= ad=20 not yet been begun. This experimentation was possible only because a=20 programmable display editor existed. It would not have been possible to des= ign=20 the EMACS standard command set without it.=20 Nor can one maintain the position that it was right to create EMACS this wa= y=20 because it was research, but ordinary system development is a different mat= ter.=20 This is because the difference between the two is also a matter of hindsigh= t.=20 EMACS was not the result of an intentional "editor research project" (nor w= ould=20 such a project have arrived at EMACS, because research projects aim only at= =20 goals which are visible at the start). The display processor and command=20 dispatcher were seen only as an improvement to TECO; no one could have=20 known, when any step was taken, how much farther the path would lead. One=20 cannot even identify a "first" step, because the development, until the wri= ting of=20 EMACS per se, blends smoothly back into the development' of TECO.=20 But why isn't such program of exploration doomed to be sidetracked by a bli= nd=20 alley, which nobody will realize due to the lack of a planned goal? 'it is = the=20 extensibility, and a flexibility of mind, which solves this problem: many a= lleys=20 will be tried at once, and blind alleys can be backed out of with minimal r= eal=20 loss.=20 Eli Zaretskii writes: >> From: Richard Stallman >> Date: Mon, 21 Dec 2020 00:47:18 -0500 >> Cc: abrochard@gmx.com, bugs@gnu.support, emacs-devel@gnu.org >>=20 >> > I wonder whether the survey stems from lack of vision of emacs >> > admin and developers. For instance, Gcc has a Development Plan. >> > Suggestions for changes to the plan are discussed on the Gcc >> > mailing list and can be approved or rejected by the Gcc Steering >> > Committee. How about Emacs? >>=20 >> GCC has many developers who are paid by various companies. >> That makes it easier to make plans and actually carry them out. > > There's another important difference. GCC implements programming > languages defined by evolving standards that are developed by other > bodies. The evolution of those language standards largely defines the > GCC development plans. Other project, like GDB, Binutils, etc. have > similar traits: they support hardware and software standards developed > elsewhere. > > But Emacs is its own standard, defined by what we put into it, it > depends very little on outside developments, and is only tangentially > affected by those external developments. So those developments cannot > determine our plans anywhere near to how the next C++ Standard affects > GCC development, or the next DWARF2 version and various > debugging-related features in the next generation of CPUs affect GDB > development.