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 <mwgam...@gmail.com> 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