Re: [Bug-apl] Request for feature: Embedded mode

[Elias Mårtenson]

Yes, this would certainly be preferable. Right now, all the configuration that is needed is to specify the path to the apl executable. It'd be nice if that was the extent of the needed configuration.

I've currently come quite far in working with what I've got (for example, I'm circumventing the ")ERASE" message by first issuing a 'IGNORE-START-HERE-XXXX' before the operation, and a corresponding STOP message after. The input filter then avoids displaying any output between these tags.

Having the --emacs flag would help with the error message thing though, since it's impossible to workaround that limitation. Also, it would be great if, when enabling that flag, the prompts were written to OUT instead of IN. The behaviour of the stuff written to IN is really strange (it disappears on Emacs in Linux, but appears in Emacs on OSX). So a nice workaround would be to simply dump it all to OUT. I have to filter it on the Emacs side anyway.

All that aside, I should soon be at the point where the interactive mode can be labelled "usable". I still have to work on syntax highlighting and dynamic documentation, but that's for later.

Here's the Github page for the record: https://github.com/lokedhs/gnu-apl-mode

Regards,

Elias

On 10 December 2013 00:07, Juergen Sauermann <address@hidden> wrote:

Hello Elias,

I think most of the things below do already exist. Lets say you write the
following in the preferences file for GNU APL:

  Color         ANSI (default)

  CIN-SEQUENCE           5b 5b 20 49 4E 20 20 5d 5d     //   [[ IN  ]]
  COUT-SEQUENCE          5b 5b 20 4F 55 54 20 5d 5d     //   [[ OUT ]]
  CERR-SEQUENCE          5b 5b 20 45 52 52 20 5d 5d     //   [[ ERR ]]
  RESET-SEQUENCE                                        //   nothing

Then GNU APL produces this:

[[ IN  ]]      1 + 2
[[ OUT ]]3
[[ IN  ]]      ]log 5
[[ ERR ]]    Log facility ' ...    function find_closing()     ' is now ON
[[ IN  ]]     
     
     
      2 + 3
[[ OUT ]]5
[[ IN  ]]

The channel tag [[ IN/OUT/ERR ]] is sent whenever GNU APL switches from one channel to another.
We could create an --emacs commandl line option that sets it to any value you prefer (no need to
be fully configurable) so people would not need to modify the preferences file.

The stderr printout on )ERASE should have gone already; there may be some printouts to CERR left
over here and there, but they should be removed over time.

The CIN channel is used for printing the prompt and for making the ⍞ prompt editable (a somewhat
awkward feature of ⍞ input). The echoing of the user input is done by eg. readline, not by CIN.

CIN and COUT both go to stdout and you can use the tags above to distinguish them.
Normally the prompt is 6 blanks which is easy to overlook. If the prompt is not-editable
(and the 6 blanks prompt is not) then the prompt is displayed by readline and not by CIN,
which is my best explanation for not showing up in emacs. With readline disabled you
may see it.

/// Juergen

On 12/09/2013 03:23 PM, Elias Mårtenson wrote:

On 9 December 2013 21:42, Juergen Sauermann <address@hidden> wrote:

Hello Elias,

I have added a command line option ---rawCIN that disables initialization and use
of the readline library, see SVN version 50,

Thank you for the update. I've taken a look at this, and it's much 

  

Not sure though what you mean by differentiation between status info and function
output. GNU APL writes APL output to stdout (actually cout) and debug output to
stderr (cerr). 

⎕CR returns a character matrix which is only printed if the returned value is not assigned
to a variable. You can catch it by VAR←⎕CR and then nothing will be printed. Same for
user defined functions (if written accordingly).

My issue with prompts is that when a process is run inside Emacs, there is no way I can differentiate between stderr and stdout. Also, there needs to be some kind of prompt, since that is what Emacs uses to detect that the underlying process is ready to receive data. If, somehow, I can ensure that nothing that is normally printed from a program can be confused with a prompt, this improves the robustness of the Emacs mode.

One thing I haven't quite figured out is how your CIN variable works. It kinds seems as though it simply prints to stdout, but nothing printed using CIN ever shows up in my Emacs buffers. I guess I'm not good enough with C++ streams to understand why that is the case.

So, in summary:

A prefix before error messages will allow me to, for example, colour them in a standout colour.

By diagnostic messages, I mean for example the message that is printed by )ERASE. The function editor window uses this behind the scenes when it redefined a function, and right now it causes a "ERASEd 'variable'" message to simply pop up in the interaction window since I can't filter it out.

Emacs can't see anything written to CIN (I wonder why that is...)

Thoughts?

Regards,

Elias