The Future of Emacs, Guile, and Emacs Lisp

http://lwn.net/SubscriberLink/615220/45105d9668fe1eb1/

by signa11 • 12 years ago

173 44 12 years ago

JadeNB• 12 years ago

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".

goldfeld• 12 years ago

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.)

danohuiginn• 12 years ago

I don't think anybody is proposing to move away from emacs lisp as the usual scripting language. Rather, you'd initially move to Guile's implementation of emacs lisp, and potentially later allow use of other languages supported by Guile.

Crito• 12 years ago

This is exactly right. The proposal is to change elisp implementations. elisp the language won't be going anywhere anytime soon.

cammsaul• 12 years ago

I find http://hyperpolyglot.org/lisp to be extremely useful for cases when I know what I want to do but don't remember how to do it in Elisp.

mitchty• 12 years ago

Brilliant, thank you very much!

vithlani• 12 years ago

Awesome resource.

ordinary2• 12 years ago

A word of warning for Elisp hackers: the Emacs Lisp part of that resource was written by someone with a CL background. I'm seeing various examples that are not conventional Elisp. For instance, ' is used instead of #' for function quoting in various places (prevents compilation of the function) and use of eval on a form instead of apply on a list (dangerous and also prevents compilation of the form). In addition, many of these features use the cl package at runtime, which will cause the compiler to throw a warning, because it's not allowed in Emacs proper.

That said, there's a lot of information here that's very useful for the starting Elisp programmer.

melling• 12 years ago

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

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

abroncs• 12 years ago

That, or contribute to Neovim https://github.com/neovim/neovim

charlieflowers• 12 years ago

Sad to see you were downvoted. It's definitely a legitimate point of view that at least deserves to be brought up.

TheCondor• 12 years ago

I love emacs and it pains me to agree with this, at least in part.

It has reached an odd place, there is enough legacy code (or so it's believed) that it can't be abandoned, there are clear innovations that will never go in to elisp (jit compilation, threads, Ffi, etc) and guile isn't being accepted while it is clearly the best way forward that has been suggested. It's like emacs is done.

Considering something else only makes sense...

krupan2• 12 years ago

XEmacs? I remember when it was the more modern emacs and I was younger and had to have all the new things. After a while I noticed that gnu emacs had picked up everything that xemacs had and was better maintained so I switched back to gnu. Maybe another fork like that could drive emacs forward. The more adventurous emacs users could use and drive the fork forward while other can stay comfortable with regular gnu emacs for a while longer.

chriswarbo• 12 years ago

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.

That's throwing the baby out with the bathwater. The only thing which makes Emacs-on-Guile difficult is backwards compatibility. If you find Sublime a viable option, then compatibility isn't an issue for you; in which case there's nothing preventing you from using Emacs-on-Guile right now.

pjmlp• 12 years ago

For me that boat sailed a long time ago, around 2005.

Since 1996, Emacs was a kind of IDE replacement when I was in UNIX environments and could not use my beloved MS-DOS/Windows IDEs, but nowadays UNIX systems also enjoy quite powerful IDEs.

webkike3• 12 years ago

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.

lmedinas• 12 years ago

So i know what i have to do! Upgrade all my machines to the new version.

September/October/November is definitly the best season of the year. New iOS, Android L, OSX, Ubuntu and of course Emacs :) i hope i'm not missing anything.

rbanffy• 12 years ago

At least for Ubuntu, Christmas comes twice every year.

sdevlin• 12 years ago

What are dynamic modules?

webkike3• 12 years ago

Dlls essentially. http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries...

klibertp2• 12 years ago

Dynamic module support

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

euid• 12 years ago

I think it would be a tremendous waste of effort to rewrite Emacs libraries in any language other than Emacs Lisp. Thus, what interests me is the idea of supporting other languages in addition to Emacs Lisp.

https://lists.gnu.org/archive/html/emacs-devel/2010-04/msg00...

Common Lisp is extremely complicated and ugly. When I wrote GNU Emacs I had just finished implementing Common Lisp, and I did not like it much. It would bloat Emacs terribly, and documenting it would be hard too.
Scheme is elegant, and it is a better direction to move in.
Since we have our own Scheme implementation, we should use that one. If it has a serious disadvantage, we should do something about that. There are various things that might be right to do, but simply disregarding it in the case of Emacs cannot be right.

https://lists.gnu.org/archive/html/emacs-devel/2010-04/msg00...

jordigh• 12 years ago

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.

dimitar• 12 years ago

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

krupan2• 12 years ago

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

mahmoudimus2• 12 years ago

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• 12 years ago

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• 12 years ago

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.

SloopJon• 12 years ago

Previous discussion of the email thread that prompted this article:

https://news.ycombinator.com/item?id=8328206

wtbob• 12 years ago

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.

The Future of Emacs, Guile, and Emacs Lisp

Related Stories