The Future of Emacs, Guile, and Emacs Lisp | Hacker News Reader

The Future of Emacs, Guile, and Emacs Lisp

lwn.net

173 pointssigna1144 comments

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.

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.

At least for Ubuntu, Christmas comes twice every year.

What are dynamic modules?

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

So... it allows us to download pre-compiled packages?

If so, it seems like it might be a big step backward for portability. One of Emacs' big advantages has been that it (and most of it's packages) work on every major desktop operating system. I share a common configuration between Linux and Windows. If this weren't possible I'd probably start looking for a different editor.

There actually wasn't very much discussion on this. There are many features of Emacs that can be turned on or off based on the system, and this is just one more.

Allowing new packages to support platform specific FFI is not going to decrease the portability of the existing ecosystem. In addition, I don't think there is anything precluding FFI calls from working on multiple platforms so long as those libraries are available.

And this is the key part. As soon as we start getting Linux only packages that depend on some library easily available only on Linux, Windows users will be pushed off.

So far Emacs has been, for many users, nice abstraction over the OS. As soon as I'm not able to use the same packages and have the same setup on both Linux and Windows, I won't use it anywhere and start looking at the alternatives.

How is this any different than functionality that requires a specific executable to be called from Emacs. Some of those executables are platform specific. Last I checked using ispell on windows meant playing games with cygwin or some other fix.

The purpose of this is not to limit functionality to a specific platform, it's to expand the capabilities of Emacs. My understanding is FFI is intended to work on all platforms that Emacs support, so it just means the library authors need to provide platform specific support, just the same as they do with packages that depend on specific binaries in the path.

Throwing out a new feature that provides obvious benefits because of imagined future packages that may choose against being platform agnostic seems rather short sighted.

> Dynamic module support

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

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

No, I know this, I was talking about exposing FFI to Elisp, for loading dlls/shared libraries which I assumed "dynamic modules" referred to. IIRC RMS said that this would encourage writing Emacs extensions in non-free fashion and distributing them as blobs instead of in the form of source code.

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.

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

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

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.

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

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.

Brilliant, thank you very much!

Awesome resource.

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.

>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

I don't see how these are evidence of the author having "CL background". CL is pretty much identical to Emacs lisp with regards to both of these things.

Truth be told, I know nothing of CL. I do know quite a bit about Elisp, and since it's not an Elisp-ism, and the CL and Elisp columns share so much identical code (a lot from cl.el), I assumed it was a CL-ism. My bad.

the #' in CL and Elisp are not the same. Elisp is a lisp-1 vs CL 'lisp-2'. The only similarity is that #'foo expands too (function foo). In CL (function foo) looks up foo in the function namespace (and iiuc can be omitted where functions are expected) in elisp the function form is like quote except for when byte-compiling. It allows the function to be byte-compiled.

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

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

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.

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

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

Are you living in the real world? The complexities are around keeping a stable platform that some of us have been using for 10-15 years with few complaints.

As with any corporate product, you can't go changing shit when you have a large paying userbase.

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.

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

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.

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.

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.

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.

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/ - [2] http://www.emacswiki.org/emacs/GuileEmacsTodo - [3] https://www.google-melange.com/gsoc/project/details/google/g...

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

Previous discussion of the email thread that prompted this article:

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

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

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

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

Reply on news.ycombinator.com