Hi Elias,
didn't I?
* if (uprefs.emacs_arg)**
** {**
** t4 = NativeFunction::load_emacs_library(uprefs.emacs_arg);**
** }*
/// Jürgen
On 05/18/2014 01:35 PM, Elias Mårtenson wrote:
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 <mailto: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
<mailto: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
