Hi! Think I ran into a bug when using the tall mode control code as part of a longer string (that then undoes it).

Seems like tall mode retains the doubled line height even after it's turned off in the same string. The following code produces this output:

cls()
?"\n ⁶t hi \n\n ⁶-t l1  \n  l2 \n"

...when I'd expect it to produce this ("l1 \n l2" is no longer in tall mode, so the height of the line break shouldn't be doubled):

It seems like the only way to revert to normal line height is to start a new print command, but that's another 2 tokens! This is affecting a WYSIWYG-style static text editor I'm planning on releasing.

I think the problem is the space after the newline but before switching off tall mode. The space itself is still being printed in tall mode hence you're getting tall mode spacing even though the actual text is normal size.

This gives the expected output:

cls()
?"\n \^t hi \n\n\^-t  l1  \n  l2 \n"

Thanks for taking a look! That did seem to fix that case, but actually in trying to simplify the bug for BBS I avoided the bug I was seeing with my original use case!

Instead of a newline after the tall line, the issue appears with using \^j to jump to a different position on the screen:

cls()
?"\^t hi \^-t \^j06 l1 \n l2\n"
--   ~~~~    ~~~~~~~~~~~~~~~~~
--   tall         not tall

produces:

I added the spaces for clarity - just to make sure, this version without any spaces also demonstrates the bug:

cls()
?"\^thi\^-t\^j06l1\nl2\n"
--   ~~    ~~~~~~~~~~~~~
--  tall      not tall

Okay, I think I get it! If we add a third line to our jumping example above, the line break does get reset properly:

cls()
?"\^t hi \^-t \^j06 l1 \n l2 \n l3 \n"

So it seems like once tall mode is enabled, the height for the next line break is doubled, regardless of whether tall mode is turned off before the break (that seems like intended behavior, for lines that mix tall and non-tall mode). This just interacts strangely with jumping because jumping isn't actually a line break, it simply moves printing elsewhere.

So to get the expected output with jumping, the workaround is to print a newline before the jump. Going to mark this as resolved.

Thanks for helping me debug @jasondelaat!

Is this actually resolved or have you just found a way to work around the bug?

If it's a workaround, the bug remains and shouldn't be marked resolved.

At this point I'm actually not sure whether to consider it a bug or a feature request (that I wouldn't really be asking for anymore).

I think the current line break behavior of mixing non-tall mode and tall mode makes sense, the question is whether doing a jump should break that behavior and "reset" the next line break to normal. To me, it's cleaner if the tall-mode line break rule stays consistent, because jumping doesn't always count as a line break.

Maybe it's a bit contrived, but I think there's a use case for wanting to jump horizontally after a tall-mode line, then do a line break (or in fact have the text after the jump wrap around!), and have that properly be underneath the tall text, e.g.:

Going to reclassify this post as a non-bug, but happy to hear other opinions!