Re: Emacs Lisp's future

[Rasmus <rasmus@gmx.us>]

Hi Stephen,

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Nic Ferrier writes:
>
>  > I am torn between a much more open and distributed Emacs (which I
>  > suspect rms won't like)
>
> What's not open or distributed about Emacs?  Maintaining legal
> paperwork is a cost and an inconvenience, but the GPL itself legally
> guarantees openness and in practice Emacs development is highly
> distributed.  ELPA is only going to provide more cases where people
> want to "sign papers", or to gather "papers" from their coauthors.  I
> can't see this as a problem -- Emacs will acquire more copyrights than
> it would have otherwise.
> [...]

Perhaps a more realistic issue is if something that should be in core
cannot be.

Say "next Org" (or whatever...) emerges and everybody agrees that it
should be in core.  Developers of "next Org" sign the paperwork.  But
"next Org" depends on "popular foreign library".  Now you've got an
issue.  The Emacs tarball is no longer enough and I need to maintain a
portable installation including an init file with "popular foreign
repo" to get to work on, say, foreign PCs.

It is an issue whether infant "next Org" knows it's "next Org".  If it
knows, it cannot use "popular foreign library" although it would
enhance development.  If it doesn't know it's "next Org" you may end
up in the scenario above.

At the moment 146 packages depends on s or dash and can thus not be
included in core unless rewritten.  Assuming they all GPL'ed it may
not be a loss of freedom in the short run, but it can still have
negative dynamic effects.

>  > But that's what we did when we introduced packages. How else did
>  > people think it would end?
>
> Huh?  Packages simply are a way of making long-standing practices
> (development and distribution by satellite projects) more convenient
> for end users, permitting multiple development cycles for "core"
> modules if desired by the core developers, and to some extent blurring
> the line between core-developer and end-user convenience.

Agreed.

> [...]


> The practical problem created by packages is (to some eyes) a blessing
> in disguise.  By enabling convenient separate development and
> distribution of many more Lisp packages than would otherwise exist,
> separate from Emacs core, it "exports" many APIs that would otherwise
> be considered internal.  [...].

One does not preclude the other.  Last I checked Company was hosted on
github.  Org and Gnus live in separate repos.  The

API argument goes over my head.  Isn't the only API in questions
#autoload of functions?  Or do you have Richard comment on changing
functions in mind?  If disputing the latter, it has been pretty
convenient for Org.  Nicolas (the author of ox, the org exporter) has
changed all exporter in org-core and org-contrib at once, after making
changes to ox.  That option is very convenient when implementations
have yet to reach the (theoretical) limit of efficiency — however
that's measured.

Cheers,
Rasmus

-- 
May the Force be with you