Re: Emacs rewrite in a maintainable language

[David Kastrup <dak@gnu.org>]

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

> David Kastrup writes:
>
>  > My personal opinion is that It's unlikely to survive into GuileEmacs for
>  > mostly technical reasons.  The best one could do is make it stick when a
>  > module calls Emacs-specific functionality.  But if it uses the general
>  > GUILE stuff (namely could be called from a standard GUILE interpreter),
>  > Emacs cannot really make a licensing claim that sticks.
>
> [David pointed this out elsewhere, but I want to emphasize: GUILE
> distributed as a part of Emacs is GPL, not LGPL, and the protection of
> the GPL extends to all code in the Emacs process space.  GuileEmacs
> can be distributed only because the LGPL allows promotion to GPL.]

"process space" is not a legal concept.  It might be a programmer's
rationale of the "dynamic and static linking make no difference with
regard to whether a single work is being formed" guideline (that has not
actually been tested in court I think, with the closest likely being
deep linking of http references so far).

Nobody claims that ld.so is a derivative of all the software it ends up
sharing process space with.  Of course, like with GCC stubs and a few
other things, the licensing tends to be chosen in a manner where this
question does not need to get resolved one way or the other.

>  > I also like the availability of applications and libraries that
>  > have not been written specifically for Emacs: replacing much of the
>  > backend behind Emacs Calc with native Jacal would be an interesting
>  > feat, and there are a number of other pathways opening up.
>
> Indeed interesting, although these days I'd be more interested in
> numpy and numba.  But I agree with your word "feat"; I'd be surprised
> when it happened; I suspect Jay Belanger isn't so interested in that.
> Maybe he'll speak up.

Well, realistically speaking calc is strictly in maintenance mode even
though I applaud the addition of some music-related functions recently.
I'm not even sure that I wasn't at one time its maintainer.  At least I
remember prompting David Gillespie monthly for trying to dig up and send
over his personal tree of Calc 2.0 (which would have significanly sped
up a lot of operations, partly due to better simplifications, partly
because of using Emacs 19 floating point numbers for getting much faster
initial approximations for the arbitrary-precision math stuff than the
24-bit integer stuff from Emacs 18 could).

This kind of surgery hasn't happened and Calc 2.0 will likely die along
with Dave's backup disks.  Swapping in something like gmp would likely
require lots fewer surgical cuts, and even swapping in Jacal while
keeping most of the frontend would likely be easier for someone with the
basic skill set "Emacs programmer and maintainer" rather than "numerical
algorithm hacker".

>  > So I do see longterm goals and strategies that could be opened by a
>  > good integration of GUILE as a core part of Emacs.
>
> Sure.  I just don't see them *for me* and *right now*.

Oh, *right now* never was much of a GNU priority.  It has always been
for the long haul.

>  > The most relevant obstacle _will_ be to overcome the "don't mess
>  > with my project" stance in both Emacs and GUILE from people that
>  > have come to like the respective culture and environment of the
>  > isolated projects.
>
> Most likely. :-( But if it really looks like a great idea, RMS will
> come and threaten to knock heads, and that will be all it takes for
> all to turn sweetness and light (you and me excepted, of course ;-).

Shrug.  The whetstone opposes the knife.

-- 
David Kastrup