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

[Juergen Sauermann]

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