Re: [Bug-apl] gnu-emacs-mode on the bleeding edge

[Elias Mårtenson]

There is such a warning, but it only tells you if the opposite is true; if your native library is newer than the Lisp code. I can't warn the other way, because the lisp code can update from MELPA without the user upgrading GNU APL itself.

For my own workflow, I have set the Emacs variable "gnu-apl-libemacs-location" to point to the location of the .so file. This variable can be used to decouple the location of the library with the GNU APL installation.

Regards,

Elias

On 8 May 2014 00:53, David B. Lamkins <address@hidden> wrote:

As one of the folks who likes to use gnu-emacs-mode updates (as opposed
to the older version that's bundled with gnu-apl), I have separate
working directories for gnu-apl and gnu-emacs-mode.

Maybe there's an easier way, but here's what I've been doing to
reinstall the latest gnu-apl-mode native code after building gnu-apl:

 $ cd ~/gnu-apl/src/emacs_mode
 $ sudo make uninstall
 $ cd ~/gnu-apl-mode/native
 $ make
 $ sudo install libemacs.so /usr/local/lib/apl

It'd be nice to have an install target in gnu-apl-mode that cleaned up
all of the libemacs stuff installed by gnu-apl (the .so, the symlinks,
the .la, the .a) and replace those files with a proper install from the
gnu-emacs-mode build.


Also, would it be possible to version the libemacs library and have the
Elisp code warn in the case where the native code is not recent enough
for the Elisp code?


(As an aside: the recently added syntax coloring is great! Thank you.)