Ah, sorry. I missed that. :-)
Regards,
Elias
On 18 May 2014 22:48, Juergen Sauermann <juergen.sauerm...@t-online.de>wrote:
> 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>
> 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
>>>
>>>
>>>
>>>
>>
>>
>
