
The Future of Emacs, Guile, and Emacs Lisp - signa11
http://lwn.net/SubscriberLink/615220/45105d9668fe1eb1/
======
webkike
Emacs development is going quite incredibly right now. For those unread on the
mailing list, here are what I consider to be the most important updates of the
past week or two: * 24.4 will be released next Monday (yay!) * Dynamic module
support is near completion (or has been completed and awaiting mainline
integration). Seriously, Emacs is incredible.

~~~
klibertp
> Dynamic module support

Wait, I thought RMS is very strongly opposed to this?

~~~
jordigh
I recently had a chat with Eben Moglen and rms that suggested that requiring
such modules to state in some code-enforced way "I am GPLed" could legally be
enough (unlike Eben, I am not a lawyer, and my understanding of what Eben told
me could be incorrect). Linux does something like this, by requiring a
LICENSE_MODULE macro to be defined for some interfaces. Linux will refuse to
load that module if the license isn't GPL, or declares that this Linux is
"tainted", and the devs will refuse to support it. I forget. Anyways, Emacs
could do this for all of its interfaces and be even stricter than Linux: look
for an explicit declaration of GPLness or refuse to load the module. If a
module makes the declaration but is lying, they're in legal hot water.

Eben is just about the only legal advice that rms will really listen to. If
something like this could be done and Eben convinces rms about this, this may
ease his (in my opinion) well-founded fears against proprietary Emacs
extensions.

~~~
coryrc
non-GPL modules have a limited API, but will load, as you state.

------
goldfeld
I see the argument that Emacs Lisp is what we have and works fine floated
around by many Emacs veterans, but I wonder if they realize the unrealized
potential (opportunity cost) of keeping Guile Scheme out (as Stefan seems to
prefer, whereas RMS is in favor of Scheme), and that Emacs going forward can
probably yet produce more wealth of extensions than in the past 30 years? I
completely agree that keeping full compatibility with all existing extensions
is the absolute priority for the new Guile engine, but I myself have kept away
from coding anything in Emacs Lisp other than a simple lambda binding because
of Elisp's warts and very forgettable ways to do common things (e.g.
manipulate strings in general.)

~~~
melling
Wow, time sure does fly. I was discussing Guile and Emacs 5 years ago on
StackOverFlow. The 10 year old article that I referenced is no longer there.

[http://stackoverflow.com/questions/1663627/guile-and-
emacs](http://stackoverflow.com/questions/1663627/guile-and-emacs)

That's 15 years of talking. My personal feeling is that sometimes it's just
better to abandon projects that stagnate. There's an open source Go version of
Sublime, for example. It would probably be easier to maintain.

[https://github.com/limetext/lime](https://github.com/limetext/lime)

~~~
abroncs
That, or contribute to Neovim
[https://github.com/neovim/neovim](https://github.com/neovim/neovim)

~~~
scrollaway
Neovim is a fantastic project, even if you're not interested in vim. They are
a model example of how a FOSS kickstarter should be run.

------
mahmoudimus
Does the Guile team need to raise money? The OP suggests that it "strains the
Guile team" and mentions resources many times.

Why can't we have a kickstarter campaign for providing funds to develop a real
plan of execution for this?

Without a real plan forward, I see Guile realistically taking another 5-10
years, making it a _20-25_ year long proposal.

~~~
pm215
I think 'resources' there generally means "engineering resources", ie skilled
people, not 'funding'.

It's not necessarily easy for an open source project to translate money into
engineers. A pot of donated cash in the bank doesn't mean that the existing
developers have any more time to work on the project, or that somebody new
with the right skills and experience with the codebase magically appears. If
one or more project members happen to be consultants who can use the money to
spend six months working on Guile rather than on some other paid engagement
that's one thing; but the amount of money required to make "quit your full
time job to work on the project" financially sensible is prohibitively larger.

~~~
AceJohnny2
Indeed.

I can add that for some projects, funding _is_ useful to acquire the hardware
and infrastructure to host the project: code hosting, build servers, test
machines, bandwidth... However I doubt this is Guile's constraint.

~~~
mahmoudimus
I am in complete agreement, in the general sense, with both you and the
parent. However, I'm not proposing they hire engineers to work on the bigger
pictures of Guile, and as the parent suggests, a "magical codebase" appears.
From Eli Zaretskii's own email[1], there are some very low hanging fruit that
can be accelerated through funds -- like solving non-GNU compatibility. We can
see more tasks at the GuileEmacsTodo[2] list and the various Google Summer of
Code sponserships for Guile [3]. These sponsorships have helped Guile make
_huge_ gains in the past 4 years.

My suggestion is to just keep that momentum going, year around. I know about
the mythical man-month, etc, but in this case, some of this low-hanging fruit
can be financed.

\- [1] [http://lwn.net/Articles/615347/](http://lwn.net/Articles/615347/) \-
[2]
[http://www.emacswiki.org/emacs/GuileEmacsTodo](http://www.emacswiki.org/emacs/GuileEmacsTodo)
\- [3] [https://www.google-
melange.com/gsoc/project/details/google/g...](https://www.google-
melange.com/gsoc/project/details/google/gsoc2014/bpt/5803402760028160)

------
wtbob
> Templeton, for example, noted that Common Lisp has no feature that
> corresponds to Emacs's buffer-local variables, which are often used in Emacs
> extensions.

I don't know about that; it sounds very much like dynamic variables. It's
usual in a Common Lisp implementation to give each thread its own set of
dynamic variables (indeed, that's close to the only sane thing to do); I can't
offhand see why it would make sense just to treat buffer-local variables
similarly. But perhaps there're some semantics I'm not familiar with.

------
SloopJon
Previous discussion of the email thread that prompted this article:

[https://news.ycombinator.com/item?id=8328206](https://news.ycombinator.com/item?id=8328206)

------
dimitar
Maybe making the branch a fork will not be that bad for all parties.

~~~
krupan
I agree. Like the way Xemacs spurred general emacs advancements for a while.

------
JadeNB
The headline, which currently appears on HN as "The future of Emacs, Guile,
and Emacs", is actually the less redundant "The future of Emacs, Guile, and
Emacs Lisp".

