4 ms·

The big change for this release is direct access to shared libraries. Traditionally, emacs has executed binaries directly for all its external interaction, usi

The big change for this release is direct access to shared libraries. Traditionally, emacs has executed binaries directly for all its external interaction, using stdin and stdout for all communication. Now it will be able to call libraries and use their native APIs rather than just two text streams. This had been long resisted on the grounds that this feature could be used to link emacs with non-free code. From the ChangeLog: ** Emacs can now load shared/dynamic libraries (modules). A dynamic Emacs module is a shared library that provides additional functionality for use in Emacs Lisp programs, just like a package written in Emacs Lisp would. The functions 'load', 'require', 'load-file', etc. were extended to load such modules, as they do with Emacs Lisp packages. The new variable 'module-file-suffix' holds the system-dependent value of the file-name extension ('.so' on Posix hosts) of the module files.

taeric 10y ago
I'm curious what required this. I have to admit that the "distanced" approach of using stdin does a good job of forcing a logical boundary between existing tools and emacs. In particular, it makes debugging markedly easier, since you can usually see what the program was trying to do. That said, I do agree that just wanting to avoid non-free linked code is not productive. That ship sadly sailed and emacs seems to be losing ground to products that don't have this concern.
- ataylor284_ 10y ago
  I'm not following things as closely as I once did, but I think one of the main drivers was using gcc/clang for analysis, to e.g. make parse trees available inside emacs.
  - taeric 10y ago
    That makes sense. Though, it is a shame both of those don't just give a dump of the tree based on a flag. :( I am guessing there just isn't a good textual representation for some of these things?
jordigh 10y ago
> This had been long resisted on the grounds that this feature could be used to link emacs with non-free code. The way to ensure that modules are GPL compatible is that they have to say that they are by exporting a symbol called "plugin_is_GPL_compatible"... and this is legally binding! Like Lawrence Lessig said, "code is law".

taeric 10y ago

I'm curious what required this. I have to admit that the "distanced" approach of using stdin does a good job of forcing a logical boundary between existing tools and emacs. In particular, it makes debugging markedly easier, since you can usually see what the program was trying to do. That said, I do agree that just wanting to avoid non-free linked code is not productive. That ship sadly sailed and emacs seems to be losing ground to products that don't have this concern.

ataylor284_ 10y ago
I'm not following things as closely as I once did, but I think one of the main drivers was using gcc/clang for analysis, to e.g. make parse trees available inside emacs.
- taeric 10y ago
  That makes sense. Though, it is a shame both of those don't just give a dump of the tree based on a flag. :( I am guessing there just isn't a good textual representation for some of these things?

jordigh 10y ago

> This had been long resisted on the grounds that this feature could be used to link emacs with non-free code. The way to ensure that modules are GPL compatible is that they have to say that they are by exporting a symbol called "plugin_is_GPL_compatible"... and this is legally binding! Like Lawrence Lessig said, "code is law".