Okay, did you do the other parts? Meaning store the name of the var at 9652h, the start address of the data (not the size bytes) at 965Bh, the error location at 965Dh and the end var address at 965Fh?

Hmm, well then I am not sure what could cause the issue
Here is some code to give you an idea of how it works:
    ld de,9652h      ;115296  ;address to store the name
    ld hl,8478h      ;217884  ;ld hl,OP1
    ld bc,9          ;010900
    ldir             ;EDB0    ;copies the name in OP1
    bcall(42F1h)     ;EFF142  ;bcall(_CheckFindSym)
    ex de,hl         ;EB
    ld c,(hl)        ;4E
    inc hl           ;23
    ld b,(hl)        ;46
    inc hl           ;23      ;HL points to the start of the var
    ld (965Bh),hl    ;225B96

    ld d,h \ ld e,l  ;545D    ;points to the start of the var
    add hl,bc        ;09      ;HL is now the end of the var
    ld (965Fh),hl    ;225F96

    ld bc,4          ;010400  ;Offset into the var to error at
    ex de,hl         ;EB
    add hl,bc        ;09
    ld (965Dh),hl    ;225D96

    ld hl,ErrorMsg   ;21****
    ld de,984Dh      ;114D98  ;Where custom error message needs to be
    ld bc,14         ;010E00  ;14 is max size of message
    ldir             ;EDB0
    ld a,2Bh+80h     ;3EAB    ;Custom error
    bcall(44D7h)     ;EFD744  ;jError
    ret              ;C9      ;Don't think this is needed XD
ErrorMsg:
    .db "Oh Crap.",0 ;4F6820437261703A

For a bonus I can show errors in action with my own assembler project >.> (I haven't added nearly as much functionality as you). The errors jump to bad equates/labels or non-hex digits were hexadecimal is expected.

Ah, now I see where you would need that. I took a peak at the bcalls, but I have not found a good way to do this, sorry

Here is the disassembling of gotoerr :

call addr_2
ld bc,(erroffset)
ld hl,(editcursor)
add hl,bc
addr_1
ld de,(editcursor)
call off_2
ret z
ret c
push hl
call addr_3
pop hl
ret z
push hl
call addr_5
pop hl
jr addr_1
addr_2
ld hl,(editcursor)
ld de,(edittop)
or a
sbc hl,de
ret z
ld c,l
ld b,h
ld hl,(editcursor)
dec hl
ld de,(edittail)
dec de
lddr
inc hl
ld (editcursor),hl
inc de
ld (edittail),de
ret
addr_3
ld hl,(edittail)
ld de,(editbtm)
call off_2
ret z
call off_1
ld d,0
jr nz,addr_4
push hl
call addr_4
pop hl
ld d,e
inc hl
addr_4
ld e,(hl)
inc hl
ld (edittail),hl
ld hl,(editcursor)
ld (hl),e
inc hl
ld (editcursor),hl
or 1
ret
addr_5
bit 1,(iy+apiflg3)
jr z,addr_6
call off_3
ret
addr_6
call off_5
call off_4
ret

;calls to rom page 0 that i won't disassemble (lazy me) :
off_1 = $1937
off_2 = $1B1E
off_3 = $3100
off_4 = $3A9C
off_5 = $3BBC

As you can see, the edit buffer has to be opened before calling this routine.
Also, it reads erroffset, which is relative, starting from 0.
There's a high chance this code may be called when the goto option is validated.
I'll check this.

That's okay, I have been looking at the code that is run when you actually press "Goto"  and I am trying to see if there is a bcall that matches it. Maybe ask ThePenguin77 or KermM? I know DoorsCS has its own custom error routine and then lets you jump to the offending error.

It is one of the Lovely Sequences

(I call them Lovely Sequences, I don't think anybody else does...)

But yeah, Kerm seems to have made a decent job of accessing the Goto option without making the user go through the OS menu. Though, of course, that could be a hook, now that I think about it

Maybe have the equates sectioned off into categories.

EQU1: B_CALL addresses
EQU2: Ram pointers
EQU3: GetKey and GetCSC codes
EQU4: Flags
EQU5: Tokens


Maybe split up tokens into 2 EQU files or something.


Idea: how about for the equates, you make a compressed file format for them. You could compress the equate names down to just 5-6 bits if you make the predefined ones case insensitive. Then, have the null byte actually, use a LBS instead, followed by the value. Example of structure:

[$XX (str len)][COMPRESSED STR DATA (padded to nearest byte)][VALUE]

_examp1 .EQU $9D95 ;just an example

    "_examp1" = 7 chrs * 6 bits = 42 bits / 8 bits per byte = 6 bytes (padded)
[$06][000000 000101 011000 000001 001101 010000 011100][$9D95]
In total, that is just 9 bytes. It could probably be compressed further, but this is just an example. Also, there would be better compression for longer equate strings.

Maybe have the equates sectioned off into categories.

EQU1: B_CALL addresses
EQU2: Ram pointers
EQU3: GetKey and GetCSC codes
EQU4: Flags
EQU5: Tokens


Maybe split up tokens into 2 EQU files or something.


Idea: how about for the equates, you make a compressed file format for them. You could compress the equate names down to just 5-6 bits if you make the predefined ones case insensitive. Then, have the null byte actually, use a LBS instead, followed by the value. Example of structure:

[$XX (str len)][COMPRESSED STR DATA (padded to nearest byte)][VALUE]

_examp1 .EQU $9D95 ;just an example

    "_examp1" = 7 chrs * 6 bits = 42 bits / 8 bits per byte = 6 bytes (padded)
[$06][000000 000101 011000 000001 001101 010000 011100][$9D95]
In total, that is just 9 bytes. It could probably be compressed further, but this is just an example. Also, there would be better compression for longer equate strings.

For now, i keep the idea of includes being readable and editable by the user (That's mainly why i decided to use unprotected prgms.).
If assembling is too slow, i will probably go for something similar (but hope not, since it'll be very long to convert).
Thx anyway =]

I know I just took all of what I considered the most common equates and put it into one file and had the user define their own equates if they needed (and they could create their own). If you split it up into 5 files or whatever, will they be by some category?

The idea is to have the fewest number of includes as possible.
For now, i'm thinking of using the comment feature, like, for example :

PROGRAM:ASMDINC1
:>LAB
:
:,CONTENT :
:,RAM
:,KEYS
:,TOKENS
:
:,RAM
:...
:
:,KEYS
:...
:
:,TOKENS
:...
:
:End