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"
< address@hidden>
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" < address@hidden>
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
|