I think the final syntactical release of 1.0 will be around late May.  From that point on, the syntax will be locked and any further changes will just be to the GUI.  There are a lot of features I would really like to add like scrolling the source code to where the error is like how BASIC does it, but that involves key hooks and some really tricky coding.  Also things like editing archived programs, clearing ram from within an app, and running asm programs from within an app I eventually need.  I'll have to get a lot of help from some hardcore asm programmers and I'm not sure where to turn for that.  I could always try the chats and stuff I guess.

By the way just so we're all clear, asm does not naively support on-breaks.  Instead, you have to create your own interrupt code to deal with the breaks.  So there really isn't any short term solution until I add interrupt support, which isn't that far away.

I've finished rewriting the commands list document.  It should be easier to understand and find commands.  Also, you can name programs now.  You'll see those Sunday probably.

On an unrelated note, I find it very funny that every time someone mentions a new project on these forums, everyone is immediately asking if it is/was/is going to be made using Axe Parser.  Now I realize that its a pretty neat toy at its current state, but realistically its not ready for the majority of applications yet.  There are still a lot of important features that I have been putting off like saving to files.  Not only that, but I don't feel that its as stable as it appears to be.  Major changes to the functions are coming soon.  I feel I should warn everyone ahead of time of some of these changes (not all in the next release):

• All default math routines will become signed routines.
• Logical And,Or,Xor might replace the bitwise And,Or,Xor. Either way that command will use order of operations.
• A few other functions might be given order of operations.
• Headers might become a requirement, right now they are optional.
• External libraries might use special labels.

I can foresee some other potential changes in the future.  I'd say my command set is probably about 30-40% complete right now so there are still TONS of commands I still have to add.  I do still go through the features list from time to time, so be patient if you don't see your request show up, I'll get to it eventually.

So I guess I will make 41 the [on] key since it appears to be missing.  Nice layout!  I was going to add one, but I couldn't find one on the internet and I didn't want to spend time making my own.

Yes and yes, except that you only need to include the program once and then you can call to the subroutines in the other program since they share the same labels.  You will probably not be able to add inline code from other programs since I'm trying to make it as unconfusing as possible, and you should never need that feature.  It will function more like the c-style #include directive.  So you just include the library somewhere in your program, then you can use all of the subroutines from it as if they were in the regular code.

Awesome!  I will be adding a new feature soon that lets you insert external code into your programs so you can use other people's routines and libraries in a separate package from the rest of the main code.

The {} actually are in the doc in the middle, but I am getting the feeling that the doc is starting to get so large, that I really should divide it into categories like Math, Data, Constants, etc. to make individual commands easier to find.

int() is almost always used with {}, in fact, I might even change it to imply the brackets.  But right now, its like this:

say you have a data structure like this:
[-2,-1,0,1,2]
And you want to display 2 more than the number so your program looks like this:

-2->{L1}
-1->{L1+1}
0->{L1+2}
1->{L1+3}
2->{L1+4}
For(A,0,4)
Disp {L1+A}+2>Dec
End

Try it.  It doesn't return the right number since even though FF is -1 for an 8 bit number, it is actually 00FF as a 16 bit number.  That value is 255, not -1 as a 16 bit.  So we need to extend the sign.  In general, that means that 00xx has to become FFxx so our 00FF becomes FFFF which IS -1.  This is the low level explanation.  You don't need to know the technical details of HOW it works, just know that it preserves the sign when reading bytes in RAM.

Now try this:

-2->{L1}
-1->{L1+1}
0->{L1+2}
1->{L1+3}
2->{L1+4}
For(A,0,4)
Disp int({L1+A})+2>Dec
End

Tada!

I'm almost positive that you can detect as many keys at one as you need.  I don't think there are actually any limits by the nature of the commands.

What is the effect of this though?
xor a
out (1),a
I've never seen this used.  I thought it only works when a in binary is a combination of all ones and a single zero.

getkey(0) is a good idea, but isn't getkey=/=0 basically the same thing?  I was actually planning on making getkey(0) detect the [on] button.

EDIT: wait nevermind, you were requesting an indefinite return.  Regular getkey only is true once and then gets reset back to zero.  I'll have to add that command.