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

[Juergen Sauermann]

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.

The absolute cool thing with xterm (actually with X) is marking and cut-and-paste with the
middle mouse button. I use it a lot in both APL and C/C++ and I have not seen any editor
(not even vi/vim) being able to do that like X. And the Ctrl-C/Ctrl-V of Windows (which
is unfortunately adopted by more and more GNU/Linux programs) is IMHO a pain in
the back and a good reason to change to a different operating system

/// Jürgen

On 12/21/2016 10:39 AM, Alexey Veretennikov wrote:

Hi,

Yes Emacs support is great but what to do whith the people who don't use
emacs (or can't use it comfortably for some reasons, like absense of
Alt/Meta key or being on low-performance device).
Blake's editor is just probably too old school :) 

I will try to follow the Kacper's approach combining with calling
external 'xterm' with the editor.

The Dyalog has convenient built-in fullscreen editor even in console
mode which you can close by hitting Esc key applying changes, see
example screenshot attached.

Juergen Sauermann <address@hidden> writes:

Hi Alexey,

we already have Elias' emacs support for GNU APL, which I believe is a good replacement
for IBM's built-in full-screen editor (aka editor 2). And a number of other editors have been
proposed in the past, for example Blakes's editor (see
http://www.gnu.org/software/apl/Community.html).

The named editor in APL2 uses a similar approach as ⎕FIO combined with popen() or )HOST.
I would therefore argue that the support of different editors in GNU APL (with some additional
wrappers like Kacper's) is at least as good as in APL2, and that emacs as a quasi built-in editor
is even better than that in APL2.

I have no idea how Dyalog does it but I would guess that their approach for arbitrary editors (as
opposed to built-in ones) is similar to that of APL2 or GNU APL.

/// Jürgen

On 12/20/2016 07:16 PM, Alexey Veretennikov wrote:

 Actually it is a great thread, I also agree with Christian what the
full-text editor support should be a part of interpreter (as it is in
IBM APL2 and Dyalog).

Kacper Gutowski <address@hidden> writes:

 On Tue, Dec 20, 2016 at 10:30:14AM +0100, Alexey Veretennikov wrote:

 Using )HOST Vim complains "Vim: Warning: Output is not to a terminal"
and not really useful (can't see what I type for instance).
Same if I use popen() via ⎕FIO.


)HOST and popen are essentially the same thing and they both capture
output of the command you are running.  But as they take command to
be interpreted by shell, you can explicitly redirect output to the
terminal yourself:

      )HOST vim >/dev/tty

In case of vim, which reinitializes terminal settings itself and isn't
bothered by having echo disabled, this is everything you need to make
it work.

See also <https://lists.gnu.org/archive/html/bug-apl/2016-03/msg00138.html>
for working proof-of-concept implementation of what Jürgen wrote.

-k