[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: First draft of the Emacs website

From: Marcin Borkowski
Subject: Re: First draft of the Emacs website
Date: Wed, 09 Dec 2015 22:00:12 +0100
User-agent: mu4e 0.9.13; emacs

On 2015-12-08, at 22:51, Drew Adams <address@hidden> wrote:

>> I think Drew meant something along the lines "a stable, dynamically
>> typed language with a bunch of built-in datatypes, a rich library, an
>> (optional) object system and integrated tools like a bytecode compiler,
>> interactive debugger, a docstring conformance checker etc."
> Sort of.  Yes, concentrate on the _features_ that Lisp has to
> offer, not on the name.  (We might not agree on which features
> are most important, but that's what discussion is for.)


> And point out _how_ these features are important to Emacs -
> (1) as a text editor and (2) as everything else that Emacs is,
> from a multi-language programming environment to a calendar,
> email client, personal organizer, whatever.
> The point is not to describe Lisp features.  It is to
> describe Lisp features that particularly benefit Emacs,
> and to point out how so.  "Why mention Lisp?" is really
> the same question here as "Why is Lisp helpful to Emacs?"
> Without giving an idea of _how_ Lisp features help, a
> feature list is not so useful.  A different supporting
> language could still let you define your own commands,
> and bind keys, and customize faces or whatever.  But the
> high-level, functional nature of Lisp lets you do those
> things more easily than some languages might.
> We don't want to set Lisp up against other languages.
> We do want to get across what it offers that benefits
> an editor and environment such as Emacs.
> And we can mention _Emacs_ "oddities" that (IMHO)
> contribute to Lisp's usefulness for Emacs, including:
> . Abundant hooks, which you can use to can tie in your
>   own code at expected places, to extend behavior.
> . An advice system that more generally lets you reuse
>   code, adapting it to your needs.
> . Dynamic binding (in addition to lexical), which lets
>   you reuse and adapt code just by dynamically binding
>   variables to different values.
> IOW, from the outset, Emacs intends for you to modify its
> behavior.  This is perhaps the main thing that sets Emacs
> apart.  And it takes this very seriously.  On purpose,
> almost nothing in Emacs behavior is carved in stone.

This is especially important.  Maybe it might even be a good idea to
tell people that Emacs is a "framework" (whatever that means) to write
custom text editors, which happen to contain two very good default
editors as a template and an example;-).

> Lisp is in large part what gives Emacs its power and makes
> it more than a mere text editor, even one that is highly
> customizable.  Features of the language are behind this:
> code as data, flexible ability to define macros, recursive
> functions (including higher-order), and whatever else we
> decide is important to point out.
> We haven't necessarily thought much about _how Lisp
> contributes_ to what makes Emacs Emacs, but it might be
> good to do so now.  Even a noisy argument about what is
> important, and why, could be useful in deciding what to
> tell people about what makes Emacs special.

Hear, hear!

> Personally, I would _not_ insist upon the stability of the
> language, the presence of an object system, the extensive
> integrated tools, or even the rich library.  Aside from the
> object system, those are expected of a mature language and
> are not particular to Lisp.  (Maybe mention the object system
> but, so far, it is not used much, AFAIK, especially by users.) 

I'm not sure whether I agree.  You're right that those are expected of
a mature language; the point is, that Emacs "extension language" _is_
mature (IOW, it is not a "toy language").

OTOH, many editors nowadays allow scripting in Python or JS, which are
very mature languages, too.  So maybe I'm wrong after all.

And when I think of it, I guess that it _might_ be a good idea to stress
that there is no such thing as an Emacs "plugin".  In other tools,
plugins are sometimes a second-category citizen, while in Emacs, the
user's code has access to the same things as Emacs native code.  IOW,
Emacs is a very primitive (in terms of usability as a text editor) core,
and 90% (or more) of functionality is a huge pile of "plugins", i.e.,
functions, which can be advised, redefined - all this on the fly.

Of course, my wording here is not very good, I'd have to think about it
a lot more, but you get the idea.

> We need not focus on the name "Lisp"; it is the features
> that count.  But neither should we shy away from mentioning
> "Lisp", IMO.



Marcin Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

reply via email to

[Prev in Thread] Current Thread [Next in Thread]