Ok, you can stop now. Look, if you continue, you will convince me to use Grammer over Axe for all my non-game projects. How dare you tempt me away from our lord and savior Axe Parser.

Minor update to the above.
The menu routine is now more efficient on scrolling. I did actually take advantage of the "rectangle shift up/down" routines so now it makes fewer calls to the Grammer routines, improving performance.
Here is what it looks like now:


I also remade the rectangle routines. It is 112 bytes larger, but it is cleaner code, uses 4 bytes of already allocated RAM instead of 24 bytes of specially allocated RAM, and doesn't use shadow registers (so it doesn't need to disable interrupts). As well, I added two new methods-- they both invert the border, but one clears the inside, the other sets it to black. I have no idea why that might ever be desirable, but I have all the other methods of setting the border and fill to black/white/clear/invert, so why not? (and it didn't add much to the code). Now I just need to add in left/right rectangle shifts and world domination will be mine.

Attached is the .8xk for those who need the latest.

This is just a quick update! I tracked down a critical bug in Grammer that has been around for a few of the mini releases (probably since last year). Send( was returning the wrong pointer, so if you started writing bytes to a file, you would almost certainly end up corrupting variables in RAM. Anyways, the link in the previous post now points to the corrected version

Wooh, lots of bug fixes, a few new features! Latest Release.

That looks quite nice. How does it work with font hooks? I was playing around with adding custom fonts to one of my games and I noticed that the font hook makes the OS's display routines way slower. I think that is because it bcalls the font hook and bcalls take forever. You might be using custom routines since you have variable-height font though. Do your display routines obey the font flags? (like inverse, erase behind etc.)

I can't quite figure out what you are using to display the font in the demos. It looks like you are just using the ti-basic style 'Disp' command (or PutC) since you can see the screen tearing a little when you scroll but that doesn't take variable-width font...

You should add in the clipped line routine you made if you haven't done so already. I have been using it for a while now and it works perfectly.

Okay, I've fixed a few bugs

The following kind of code was broken:
If <condition>
Then
    <<do stuff>>
    <<While, Repeat, For, or If/Then (but not If/Then/Else)>>
End:End
If the condition evaluates false, Grammer would search for the matching End token. However, I tried to be clever, and combined it with the code for when it is If without Then, and so it seeked the end of the line (specifically the newline token, colons (":") didn't count). Unfortunately, this meant that the second End was skipped, causing an outer loop to End prematurely. Oof.

In fixing this bug, I noticed another clever optimization that I had made which was really not clever and had broken "!If" for a while! !If works now


An unrelated bug is with copying data from archive to RAM if it crossed a page boundary. Once again, I thought I'd be clever and I noticed that I had an "adc hl,bc" in a place where the carry flag was guaranteed reset, so I "optimized" it to "add hl,bc" to save 4cc and a byte. Whelp, it turned out that I was using "adc hl,bc" because that one affects the sign flag, whereas "add hl,bc" doesn't. Ouch.


For loops had an update, specifically fixing the previously undocumented command For <<expr>> which would loop <<constant>> number of times. Today, @NonstickAtom785 found a bug when trying to use a variable as the expression. In actuality, it was a For bug affecting any expression that started with a pointer var! I fixed this by simply checking if the token following the pointer var was a comma. If it isn't a comma, treat it as an expression, otherwise, treat it as a normal For loop.

---

There were some updates to modules, too: I moved the verification step. Before, every time a module command was run, the module would have its header verified (look for the 4-byte magic number, then make sure the version was compatible). Grammer now verifies when you first initialize it ("5MYMOD->$) and assumes for subsequent calls to module functions that the module is still valid. This removes some overhead, but module functions are still slow to call, and likely always will be

@NonstickAtom785 : You were looking for this I think.

When I updated Grammer to 2.50, I declined to make a program launcher thing. (I used to supply an assembly program that could be used to either run a Grammer program, or execute in-line Grammer code.)

I had fun with creating this .gif showing that you can basically mix Grammer code inside a BASIC program (aside: The other way around is more difficult):


For compatibility reasons, I renamed the assembly program to prgmG250.
Inputs:
    - Ans is a string: Then it is the name of the Grammer program to execute.
    - Ans is not a string: Then the code following Asm(prgmG250 is executed as Grammer code up to a Stop,
      then it continues as TI-BASIC code.

So, some things to consider: I know when I make Grammer programs, I put subroutines after the Stop. If you tried to in-line one of those programs this way, the TI-BASIC parser would pick up at the subroutines, almost certainly causing an error! Instead, you'll want to reorganize your code like:
  <TI-BASIC code>

Asm(prgmG250
  <Grammer code>
Goto Lbl "Stop
  <subroutines>

.Stop
Stop

  <TI-BASIC code>


Basically, just make sure that the Stop that your Grammer code reaches comes right before where you want the TI-BASIC parser to pick up. In the example gif, the program I ran had no subroutines, so I didn't ave to worry about the structure.

A final note, prgmG250 should be compatible with at least v2.50.0.2 and after. I didn't check 2.50.0.0 and 2.50.0.1, but it should work with those, too.