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


On 17 May 2014 18:21, Juergen Sauermann <juergen.sauerm...@t-online.de>wrote:

>  Hi Elias,
>
> my proposal would be this:
>
> 1. we give the --emacs command line option an argument. So apl would be
> started like:
>
> *    apl --emacs emacs_arg*
>
> 2. the libemacs library provides a function emacs_start() with two char *
> arguments:
>
> *    void emacs_start(const char * emacs_arg, const char * lib_path)**;*
>
> This function would replace the *function_mux(),* g*et_signature(**),*and
> *eval_XXX()* functions.
> *lib_path* is the absolute path to the libemacs library, which is
> normally /usr/lib/apl/libemacs.so
> but can be different. GNU APL calls this function once on startup.
>
> Regarding library locations, I believe we should avoid a situation where
> every package installs its own
> library at their own place, leading to a scattered set of libraries. If a
> component needs additional libraries
> then it should install them in a standard place like /usr/lib/apl or
> /usr/local/lib/apl as determined by ./configure.
> I am also working on installing supporting workspaces (wslib3, 4, and 5)
> there.
>
> /// Jürgen
>
>
>
> On 05/16/2014 06:28 PM, Elias Mårtenson wrote:
>
> Thanks!
>
>  Now, I need to be able to pass an initialisation argument, as well as a
> way to specify the location of the library. Any suggestion how to do this?
>
>  As for the init parameter, I'm now passing it into the native function
> (it's a single number that specifies the port number to listen to, or -1 to
> use Unix domain sockets).
>
>  Regards,
> Elias
>
>
>

Reply via email to