I found that the editor glitches out when you search for the enter character. (CHR$(10))
The line numbers disappeared and the cursor was out of place.
Here's a screenshot
Bugs in the editor
Turns out the editor has some weird behaviors. We'll start where my search began, on a Miiverse thread!
On the thread linked above, you can see the editor going beyond 999999 lines. I don't know if you can trigger this just by inserting newlines manually (because that would take FOREVER), but I do know if you try to load a file longer than 999999 lines it'll just expand to fit; the same goes if you inject newlines with PRGINS. The line counter sticks at 999999 but it keeps on going. You can actually put up to 1048576 newlines, since a slot's actual source-code memory limit is 2MiB. A good fix for this bug would be to limit the slot to 999999 lines regardless of memory limits, because in most cases you're going to run out of memory before you reach it anyway.
Loading a file larger than 2MiB throws a "Not enough memory to load" dialog, but the first 2MiB of the file is loaded anyway. Funnily enough, these contents don't show up until you switch between slots (for example, load the file in slot 1, switch to 2 and then back to 1); so it looks as if the editor is empty. Trying to type anything into this empty editor just does nothing.
If you load a file, its last character is always treated as the end-of-line character for the last line, even if this character isn't a newline CHR$(10). This is exactly as it sounds like: it acts like one of those blue arrows. You can't cursor past it to remove it, so trying to insert another line just puts the character at the end of that one. Not even PRGSET works, because it auto-inserts a newline if said line isn't or doesn't have one. Your only choice is to use reset the slot (and then write a program to inject a newline on the end of that file.)
You also can't jump to the end of that line (SHIFT + Left or pushing the CP left) in the editor, because the line-seek looks for newline characters. You would have to seek to the end of the file.
A good fix for this bug would be for the editor to automatically insert a EOL at the end on load or save (many PC text editors do this.) Or, maybe, don't treat a character like a newline if it isn't one?
And finally, if the line count of the current file is past some point (the exact number I still don't know), you can't edit anything. Nothing works at all. Which is weird, since it's some point before the memory limit and backspace is also useless (and it's an editor; editing text files is the entire point of its existence.)
Loading a file larger than 2MiB throws a "Not enough memory to load" dialog, but the first 2MiB of the file is loaded anyway. Funnily enough, these contents don't show up until you switch between slots (for example, load the file in slot 1, switch to 2 and then back to 1); so it looks as if the editor is empty. Trying to type anything into this empty editor just does nothing.
If you load a file, its last character is always treated as the end-of-line character for the last line, even if this character isn't a newline CHR$(10). This is exactly as it sounds like: it acts like one of those blue arrows. You can't cursor past it to remove it, so trying to insert another line just puts the character at the end of that one. Not even PRGSET works, because it auto-inserts a newline if said line isn't or doesn't have one. Your only choice is to use reset the slot (and then write a program to inject a newline on the end of that file.)
You also can't jump to the end of that line (SHIFT + Left or pushing the CP left) in the editor, because the line-seek looks for newline characters. You would have to seek to the end of the file.
A good fix for this bug would be for the editor to automatically insert a EOL at the end on load or save (many PC text editors do this.) Or, maybe, don't treat a character like a newline if it isn't one?
And finally, if the line count of the current file is past some point (the exact number I still don't know), you can't edit anything. Nothing works at all. Which is weird, since it's some point before the memory limit and backspace is also useless (and it's an editor; editing text files is the entire point of its existence.)
Scrolling horizontally (with text wrap off) is broken
Search doesn't scroll the editor horizontally
I was playing with SmileBASIC today and I found out that the search feature won't work correctly when the text goes past the screen with text wrapping turned off. It won't scroll right if the keyword is past the screen but will highlight it. So basically when I want to search for, say for an example, PRINT, and a bunch of stuff is before it pushing it off the screen, and I search for it, it will scroll there on the Y axis but not on the X axis. So it will show all the code before it on the same line but won't scroll right to the actual word. [EDIT] I just updated to SB 3.3.0, BTW.Switching slots doesn't reset the horizontal position
Yet another reason to leave text wrap on: 1: Type a line of text that is wider than the screen 2: move the cursor to the end 3: switch slots 4: now your cursor is in the wrong place.