[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs Survey: Toolbars
From: |
Jeremy Bryant |
Subject: |
Re: Emacs Survey: Toolbars |
Date: |
Thu, 25 Feb 2021 22:53:02 +0000 |
User-agent: |
mu4e 1.4.15; emacs 28.0.50 |
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 was not
in sight.
Although I couldn't locate the original source of exact quote, there is a
longer piece
from the 1979 memo from RMS on the same subject.
Implications for the Process of System Design
It is generally accepted that when a program is to be written, specifications
should be designed in advance. If this is not done, the result will be
inferior.
Some people know better than this, but none dare to speak up.
The writing of EMACS was as far from along these lines as can be imagined. It
is best thought of as a continuous deformation of TECO into something which,
for users, has no resemblance to TECO.
And indeed, there are ways in which EMACS shows the results of not having
been completely thought out in advance, if only in being based on TECO rather
than Lisp. (Nevertheless, EMACS has shown itself to be reliable and suitable
for
widespread use). If EMACS hadTbeen specified in advance, it would resemble
the post-EMACS editors described above. However, the post-EMACS editors
were specified in advance by EMACS itself, and could not have been written if
not preceded by EMACS (this is not to say that they have copied slavishly; they
have continued the process of gradual development). And EMACS could never
have' been arrived at except in the way it actually was. The chain of necessary
steps leading to EMACS, starting with the display processor, was simply too
long
for anyone to have imagined the final result before the first step had been
taken.
If we had insisted on moving only toward destinations visible at the beginning,
we would never have got here from there!
This is true of all the details of the individual commands as well as of the
structure of the system. Each command in EMACS behaves as it does as a
result of experimentation by many different users customizing their editors in
£ MACS June 22, 1979
21
MIT Al Lab
different ways, in the years when the display processor existed but EMACS had
not yet been begun. This experimentation was possible only because a
programmable display editor existed. It would not have been possible to design
the EMACS standard command set without it.
Nor can one maintain the position that it was right to create EMACS this way
because it was research, but ordinary system development is a different matter.
This is because the difference between the two is also a matter of hindsight.
EMACS was not the result of an intentional "editor research project" (nor would
such a project have arrived at EMACS, because research projects aim only at
goals which are visible at the start). The display processor and command
dispatcher were seen only as an improvement to TECO; no one could have
known, when any step was taken, how much farther the path would lead. One
cannot even identify a "first" step, because the development, until the writing
of
EMACS per se, blends smoothly back into the development' of TECO.
But why isn't such program of exploration doomed to be sidetracked by a blind
alley, which nobody will realize due to the lack of a planned goal? 'it is the
extensibility, and a flexibility of mind, which solves this problem: many
alleys
will be tried at once, and blind alleys can be backed out of with minimal real
loss.
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Richard Stallman <rms@gnu.org>
>> Date: Mon, 21 Dec 2020 00:47:18 -0500
>> Cc: abrochard@gmx.com, bugs@gnu.support, emacs-devel@gnu.org
>>
>> > 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?
>>
>> 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.
- Re: Emacs Survey: Toolbars, (continued)
- Re: Emacs Survey: Toolbars, Lars Ingebrigtsen, 2021/02/26
- RE: [External] : Re: Emacs Survey: Toolbars, Drew Adams, 2021/02/26
- Re: [External] : Re: Emacs Survey: Toolbars, Stefan Monnier, 2021/02/26
- *Menu* buffer, Tomas Hlavaty, 2021/02/26
- Re: *Menu* buffer, Eli Zaretskii, 2021/02/27
Re: Emacs Survey: Toolbars, martin rudalics, 2021/02/25
Re: Emacs Survey: Toolbars,
Jeremy Bryant <=