Thanks. Could you also not load the library if emacs_arg is not given? This is in order to still support the old model if the user tries to use the old Emacs Lisp code.
Regards, Elias On 18 May 2014 19:14, "Juergen Sauermann" <juergen.sauerm...@t-online.de> wrote: > Hi Elias, > > I have reverted to --emacs with no argument, and added --emacs_arg with one > argument, SVN 273.--emacs_arg implies --emacs so that only one of them is > needed. > > I believe for the location override at development time a symbolic link > next to libemacs.so should do what you want. > > /// Jürgen > > > On 05/18/2014 11:33 AM, Elias Mårtenson wrote: > > Would it be possible to revert the behaviour of - - emacs and add a new > flag that implements the new behaviour? This would ensure that old versions > of the Emacs Lisp code can still function with newer versions of GNU APL. > > Also, a way to override the location of the native library is needed > (mainly for development purposes). > > Regards, > Elias > On 18 May 2014 17:24, "Juergen Sauermann" <juergen.sauerm...@t-online.de> > wrote: > > Hi Elias, > > my original plan was to have multicore support in GNU APL 1.4. Maybe I > should > shift that to 1.5 and make 1.4 a bugfix release, given the many changes > since 1,3, > > In the meantime I can update the emacs_mode subdir in SVN with your latest > changes > so that SVN is in sync again. Just let me know where and when to fetch it. > > /// Jürgen > > > > > On 05/18/2014 06:40 AM, Elias Mårtenson wrote: > >> In implementing support for this, I realise that that I'm breaking >> backwards compatibility. That is, the latest version of gnu-apl-mode will >> not be able to control an older version of GNU APL. >> >> When were you planning to release GNU APL 1.4? I think it might be needed >> to make sure everything is in sync. >> >> Regards, >> Elias >> >> >> >> > >
