6 ms·

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 pa

by webkike 12y 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 12y 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 12y ago
  At least for Ubuntu, Christmas comes twice every year.
sdevlin 12y ago
What are dynamic modules?
- webkike 12y ago
  Dlls essentially. http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries...
  - Skinney 12y ago
    So... it allows us to download pre-compiled packages?
    - arglothy 12y ago
      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.
      - webkike 12y ago
        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.
      - dgtized 12y ago
        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.
        levosmetalo 12y ago
        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.
        dgtized 12y ago
        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.
klibertp 12y ago
> Dynamic module support Wait, I thought RMS is very strongly opposed to this?
- euid 12y 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/msg00673.html 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/msg00612.html https://lists.gnu.org/archive/html/emacs-devel/2010-04/msg00...
  - klibertp 12y ago
    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.
- jordigh 12y 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.

by webkike 12y ago

lmedinas 12y 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 12y ago
At least for Ubuntu, Christmas comes twice every year.

sdevlin 12y ago

What are dynamic modules?

webkike 12y ago
Dlls essentially. http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries...
- Skinney 12y ago
  So... it allows us to download pre-compiled packages?
  - arglothy 12y ago
    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.
    - webkike 12y ago
      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.
    - dgtized 12y ago
      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.
      - levosmetalo 12y ago
        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.
        dgtized 12y ago
        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.

klibertp 12y ago

> Dynamic module support Wait, I thought RMS is very strongly opposed to this?

euid 12y 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/msg00673.html 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/msg00612.html https://lists.gnu.org/archive/html/emacs-devel/2010-04/msg00...
- klibertp 12y ago
  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.
jordigh 12y 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.