I fixed the error scrolling!!!

The trick was to learn how those stupid edit buffers actually work.  In case anyone is interested, I will explain the problem because you never know who will need it.  Basically the edit buffer moves all programs other than the one you are editing to the end (or beginning?) of RAM so that the buffer you have to work with is consecutively: All of free ram followed by the original program.  The original program is then copied to the start of the free ram (so now there are 2 copies).

Here is where the error comes in.  What happens when the program you're editing takes up more than the available ram in your calculator? (e.g. editing an 8Kb program when you only have 4Kb of ram left).  You obviously don't have room for 2 copies, so one of them has to get cut.  The way I was shifting the edit buffers originally, I was assuming that the original program at the end of free ram would get cut so the copy could be edited.  But instead, the top program was truncated.  So all I had to do was just use the handy ldir (Axe's Copy() command) to copy the original into the editing spot.  From here on, the rest of the code works the way its supposed to now that the buffers are corrected.

This is Axe's longest solution-less bug to be fixed!  The second longest was probably re-enabling interrupts correctly (Solved by our clever calc84maniac)

This also means error scrolling can finally be automatic since it won't ever crash.  No need to press [prgm] anymore, it will always take you to the error unless you press [clear].

That's not a bug, Axioms must be appvars in order to work.  Axe only allows them as programs for the purpose of converting since most assemblers cannot natively export an appvar.  Axe cannot convert the program for you if it is in archive, so it errors.  The reason I cannot unarchive, convert, and then rearchive is because the entire edit buffer is used during compiling.

I made this fun little program and I wanted to share it because its awesome.  See if you can guess what shape it draws.  
(Requires 1.1.0)

:.COOL
:.Allocate a 96x64 bitmap
:[6040]→Str1
:Buff(768)
:
:.Draw a single pixel on the screen
:ClrDraw
:Pxl-On(0,0)
:
:.Loop a few times
:1→C
:For(6)
:  .Turn the buffer into a bitmap
:  Copy(L₆,Str1+2,768)
:
:  .Draw some bitmaps
:  Bitmap(C,0,Str1)
:  Bitmap(0,C,Str1)
:  
:  .Display and iterate
:  DispGraph
:  C*2→C
:End
:Pause 5000

The disassembly looks fine to me.  All the jumps calls and everything of that nature are aligned.  I tried 4 test cases with different combinations of sign values and they seemed okay.  Since the generated picture is relatively close to the original given that it was a chaotic system sensitive to errors, I would guess it is only a few special cases that cause it to return a wrong result.

EDIT: I made a program to run them side by side on random numbers and quit when the output is different.  Here is an output that gives different results between the routines:

$FFE0 ** $F5F1 (-0.125 ** -10.059)

Results in $0143 (1.26) in size optimized.
Results in $0239 (2.22) in speed optimized.

I can do that... but then the percentage will just stand still every time it parses a subprogram which might appear like freezing.  I don't know if that would be considered better or worse.  I could at the same time display the percentage of the subprogram elsewhere at this moment.  I'll see how it looks.

I still think just using another token would be easier... it is more flexible since you don't have to use it on the same line, easier to parse, and I personally think it is easier to use and understand since it is easy to confuse exactly what the syntax is supposed to do as Builderboy has already done.  Also, by using another token, I don't mean redefining an existing one, I mean just using one of the OS tokens with its original name.  I was thinking maybe "Seq" from the mode menu?

@Happybobjr
The problem is that it won't know the size until it finishes the entire compile.  If I make it pause the size at the end, it will annoy many users who want to compile as quickly as possible.  But I just had a great idea as I was typing this.  What if I use the homescreen to display the final size of the program?  Axe clears the homescreen anyway when it quits, it might as well do something useful with it.  I like that, I think I'll add that feature.  By the way, the size displayed will not be the same as what you see in the memory management menu because it will not include the symbol table entry.

Alternatively, I could add access to Axe's temporary buffer through some new token and store it there.  The temporary buffer is an 8 byte buffer used in a few commands that create more data than can fit in an Axe variable such as Pt-Get() and RotC().  All commands so far that use this buffer also return it so it's location hasn't needed to be directly accessed yet.