[...]
I'm a long time emacs user. The following article was an eye-opener,
of a sort, for me:
http://pinard.progiciels-bpi.ca/opinions/editors.html
[...]
Could you expand on why you found that article convincing? To be
honest, it seems a bit schizophrenic to me. I can make sense of it, if
I read it as a statement of personal, idiosyncratic preferences.
That's o.k., I have my own, different idiosyncracies. But I don't
understand how that could convince anybody else.
I mean: o.k. there is that part about the author's quirks with RMS and
the FSF. Fine for him. Others might agree. I don't care. I am happy
with both RMS and the FSF. At any rate I fail to see the technical
point here.
O.k. there is that part about Python being nicer than Lisp. This comes
a bit as a surprise to me, since the author first states: "In fact,
this Lisp was more than once the language in which I chose to express,
extensively, the algorithmic solution of some problems which were
somehow related to editing tasks." Then he goes on to complain about
the fact that Emacs Lisp does not lend itself very well for tasks not
immediately related to Emacs-the-editor. I can agree with that so
far. Later on he ditches Lisp in favour of Python and complains about
how bad Emacs supports Python. Again, fine for him if he prefers
Python. I don't. IMO, this boils down to the ancient
what-is-the-best-language-of-the-world issue. Surely interesting, but
IMO hardly a very convincing argument against Emacs.
Except, one would reason from this that Emacs should support multiple
extension languages like Vim supposedly does. The author himself can
hardly argue for this, because he complains about the already existing
complexity of Emacs. Now Emacs Lisp is not just an extension language,
it is a language in which the program itself is implemented[1].
Supporting multiple extension languages equally in this way would
*boost* Emacs' complexity, assuming that it is feasible at all.
Maybe I can make sense of the argument, if it is meant to convince that
Vim's design is better: being restrictive in the jobs it attempts to
do and leave everything else to other programs. Maybe I can force
myself to gain some understanding how that could convince somebody to
switch to Vim. But to Eclipse? Honestly!
Speaking of it, there is his introductory point about Emacs'
complexity which has become too much for him, as he states. (The text
is btw. quite of date in a few points, but anyways ...) He does not provide
many technically relevant examples. I agree that the display engine is
arcane stuff. Personally, I have completely failed to understand it.
Maybe Mule is also difficult, I don't know. However, for both there
does not seem to be a lack of people who are able to deal with it. (I
was not there, but I could imagine that implementing UTF-8 as new
internal format has been the source for a lot of headaches. But hey!
we are talking about reaping out the internal representation of text
in a large program that is focused on text and replacing it with
something entirely different. Name one similar programming project
where something like that has been easy!)
Well, of course, if you want to grok *all of Emacs*, then you are in
serious trouble. I just don't see why anybody would want that. I
dare to say that there is not a single person in the world which
understands and has an overview over *all* of Emacs. The charm is
that this is not necessary. It is one of the strength of its design,
that Emacs may grow rather organically.
Oliver
Footnotes:
[1] That Elisp is both, is a critical part of Emacs' design.
This---together with the interactive nature of the language---is what
makes the difference between an Emacs in the generic sense and an
Emacs-like editor.
