Hi,
providing descriptions of functions is a lot of work. Most people know
APL after
a short while, and those who need it are probably better off with a good
APL book.
I wanted to wait with the next release until the rate of error reports
goes down a little.
Right now it seems to get a little more quiet, so maybe in two weeks
from now?
/// Jürgen
On 03/01/2014 05:22 PM, Elias Mårtenson wrote:
Thanks. Looks easy enough.
What do you think of the idea of having descriptions of the functions
embedded in the APL interpreter instead of in the Emacs mode?
Secondly, when do you plan to release 1.3?
Regards,
Elias
On 1 March 2014 23:50, Juergen Sauermann
<juergen.sauerm...@t-online.de <mailto:juergen.sauerm...@t-online.de>>
wrote:
Hi Elias,
for commands, you can #define macro cmd_def() and then #include
Command.def.
For Quad-vars you can #define macros ro_sv_def() and rw_sv_def and
then #include SystemVariable.def.
For example, to get the strings for all commands:
#define cmd_def(cmd_str, code, _arg) #cmd_str
#include "Command.def"
To get the strings for all quad variables:
#define ro_sv_def(var) #var
#define rw_sv_def(var) #var
#include "Command.def"
In the latter case you need to replace "Quad_" by "⎕". Or #define
the macro as ID_ ## x (which gives an enum Id) and call id_name()
on it
to get an UCS_string.
/// Jürgen
On 03/01/2014 02:42 PM, Elias Mårtenson wrote:
I've recently added smart expansion of symbols in the Emacs
mode (press TAB and get a list of suggested variable and
function names). I'd like it to be able to expand system
commands and quad commands as well. Of course, I could simply
hard-code the list of available commands, but it would be
neater if there was a way of accessing this from GNU APL itself.
Also, since the expansion list has room for a description, it
would be even more awesome if I could access a one-line
description of these commands and variables. Of course, I
could include it on my side, but this is something that's
useful for not only the Emacs mode, but for any user of GNU
APL, so would it make sense to include this information in the
interpreter itself (I'd access it through an API, while it can
also be made available from some kind of help command from the
commandline).
Regards,
Elias
