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

[David B. Lamkins]

No worries, Jürgen. My choice of project name is a poor representation of the 
scope of its capabilities.

On Wed, Dec 21, 2016 at 09:31:01PM +0100, Juergen Sauermann wrote:
> Hi David,
> 
> truly sorry that I forgot to mention it.
> 
> /// Jürgen
> 
> 
> On 12/21/2016 08:55 PM, David B. Lamkins wrote:
> 
>     This seems like a good time to again mention my APL package manager.
> 
>     [1]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.
> 
>     [2]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.
> 
> 
> 
> References:
> 
> [1] https://github.com/TieDyedDevil/apl-pkg
> [2] https://github.com/TieDyedDevil/iso-apl-cf