RE: [External] : A peek to the other side

[Drew Adams <drew.adams@oracle.com>]

[-- Attachment #1: Type: text/plain, Size: 2511 bytes --]

> If you didn't you don't know how lucky you are with the integrated
> Elisp manual. It doesn't have an integrated manual, you have to browse
> a huge HTML file to find some API call...

The built-in help and thorough-going introspection of
Emacs and Elisp are in fact outgrowths from Lisp and
the Lisp community.  Lisp has had this strength from
the outset.

And RMS has always had a strong will to keep Emacs
open and self-aware/self-documenting.  "Doc", in
multiple senses, has always been important to Emacs.
And Eli has continued this practice and direction.
We've all been lucky for such attention to doc/help.

> And as usual with APIs (unlike Emacs' open system) you can only access
> what the developers expose via the API which is very limiting compared
> to Emacs.

Yep, free, open code, down to the bit-level.  It's
free turtles all the way down.

IMO, even the notion of "internal" variable, function,
or other Lisp construct is a misnomer in Emacs.  (I'm
in a minority on this.)

That "internal" label can/should never mean more than
a _relative_ and rough indication of some imagined
probability that the thing might change.  Everything
might change, and nothing is really "internal".

Unfortunately, there's been more of a tendency in
recent years to "name-claim" more things to be
"internal", as if that somehow protected something or
someone (Emacs development/developers? Elisp users?).

As always (esp. with Lisp), some things whose creator
never thought of as possibly useful or needed outside
the initial context do find useful uses by _users_.

By using something thought/intended to be "internal",
users can discover real uses and put to the lie the
notion that the thing should be considered internal
or in some way restricted.

The tendency to think in strong black-&-white,
internal/external, baked/fluid, closed/open terms
comes also (I think) from the fact that developers
come to Emacs and Elisp from working with other, more
static/structured languages and environments - worlds
where there really can be a strong use and need for
an inside/outside separation and protecting coders
from themselves and code from itself (beyond purposes
of abstraction).

> You can't change everything, so you don't shoot yourself in the foot. I
> prefer Emacs' approach where I can even break the system, which is a
> great learning experience.

Indeed.  Not only learning for an individual, but
discovering and inventing for everyone.

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 14754 bytes --]