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 On 17 May 2014 22:54, Elias Mårtenson <loke...@gmail.com> wrote: > Fair enough. I'll implement this tomorrow and will let you know how it > went. > > Regards, > Elias > > > On 17 May 2014 22:51, Juergen Sauermann <juergen.sauerm...@t-online.de>wrote: > >> Hi Elias, >> >> SVN 271. >> >> I think emacs mode is special because it survives )LOAD and is not >> visible on APL level. >> >> If we would allow that in general then troubleshooting could become >> rather tricky because >> you cannot easily figure the state of the interpreter. >> >> By enforcing the use native functions for of loading shared libraries we >> have everything in >> the workspace (even if you dont normally use workspaces) and can send it >> for reproducing faults. >> >> /// Jürgen >> >> >> >> On 05/17/2014 03:58 PM, Elias Mårtenson wrote: >> >>> I am OK with this, and it would certainly fill all current needs for the >>> Emacs mode. >>> >>> I personally feel that this should be more generic (ability to load more >>> than one library; decoupling it from the --emacs flag). The decision is >>> yours though, and the Emacs mode works equally well regardless of whether >>> the facility is generic or not. >>> >>> Please let me know when this facility is made available, and I will >>> adapt the Emacs mode to conform. >>> >>> Regards, >>> Elias >>> >>> >> >
