Re: [Bug-apl] Calling external editor from APL session

[David B. Lamkins]

This seems like a good time to again mention my APL package manager.

https://github.com/TieDyedDevil/apl-pkg

This provides, among other things:

 - a way to organize APL code,
 - analysis tools, and
 - editor integration.

I'll start with editor integration, since that's the current topic of interest. 
You can edit any function that the package manager has loaded with the command:

      ]pkg edit <function-name>

This opens the function in an external editor, positioning the cursor to the 
header line of the function within the .apl file from which the function was 
loaded.

The editor itself defaults to `vi`; this can be be changed by naming your 
favorite editor in the package manager's configuration file. In the editor, the 
keyboard is mapped for APL without using `loadkeys` or `xmodmap`.

The package also provides a wrapper script `awe` (for APL Workbench 
Environment) that, among other things, establishes a proper environment to 
support the editor. By default this is `dvtm` in the Linux console and your 
window manager under X. The `awe` script also supports `tabbed` (an XEmbed 
container) and `dvtm` under X.

The package manager's analysis tools include:

 - apropos (find APL functions, variables or operators by partial name)
 - refs (list all non-local names referenced by a function)
 - uses (list all functions that use a given user-defined function, variable or 
operator)
 - undefs (list names referenced but not defined)
 - unrefs (list named defined but not referenced)
 - locate (identify the file from which a function or operator has been loaded)
 - inspect (inspect/edit variables via navigation of their nested structure)

Then there's the actual package management functionality. Simply put, a package 
is a collection of source code in one or more .apl files. A package may depend 
upon other packages; dependencies are loaded as needed. You may program the 
package loader (on a per-package basis) to perform different actions depending 
upon certain environmental queries, e.g. what's the OS?

A package's loader may shell out to do non-APL things. For example, you can 
compile the code of a shared library to be loaded as a native function using 
GNU APL's quad-FX extension.

All of the above is already implemented. I use the package manager to develop 
the package manager and some other utility libraries, such as my ISO-compliant 
component file library.

https://github.com/TieDyedDevil/iso-apl-cf

In the longer run, I intend to implement versioned dependency loading and the 
ability to load packages from the `net.



On Wed, Dec 21, 2016 at 01:35:36PM +0100, Juergen Sauermann wrote:
> Hi Alexey,
> 
> I am myself not familiar with emacs and, as a matter of fact, I do not even
> have it
> installed on my machine. I believe the most efficient way to write APL 
> programs
> these days is to edit the functions and variables offline in a separate .apl
> file which
> is then run in a separate window. Like you write a C/C++ program beforehand.
> compile it, and then execute it. With that approach you can use whatever 
> editor
> you prefer and you have all the functions and variables in a single file and 
> in
> a
> consistent state. It also simplifies the documentation and publishing of APL
> programs lot.
> You can also check-in the .apl files into a revision control system, diff 
> them,
> and so on.
> 
> The interactive mode of APL (including function editing) has always had severe
> limitations
> and I have provided it only for compatibility and for the elder APL 
> programmers
> who are used to it.
> The interactive mode was definitely an improvement over the punch cards used
> when APL was invented,
> but today the capabilities of computers are very different and I would not
> recommend the interactive mode
> for newcomers to APL.