Hacker News Reader

Comment by webkike | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com