Hello @zep. I had to dig into the bug where text in text editors would overlap for some reasonand I noticed something: on Windows, the following snippet causes the issue 100% when pasted from notepad:

adasd

the game

Of course, I don't think copy-pasting it from here would work. As a matter of fact, there should be two blank lines and there's only one, so there's something altering the text, be it the BBS, the browser or something else.

So, I hacked in gui_ed.lua:insert_multiline_string a way to read the string and its hexdump in the console log in the following snippet. It's ugly but it's functional.

local res = ""
--str = str:gsub("\r", "") -- I'll get to that
for i=1, str:len() do
	local c = str:sub(i,i)
	local co = ord(c)
	local cs = c
	if co < 32 then
		cs = ("<%02x>"):format(co)
	end
	res ..= ("[%s][%02x]"):format(cs, co)
end
printh(res)

I spotted the presence [<0d>][0d][<0a>][0a] in console log, the classical CRLF. In that function, you're splitting by \n and I got a certain suspicion that happens when you mix reading text and Windows. Listing the pasted line's last characters got me on track: \r, a.k.a. the carriage return. That characters stays at the end of the line after the editor's code tries to split the clipboard content by the newlines. And because that character actually does a carriage return like the standard, the text following the character gets moved back to the start of the line and presto, it's overlapping text time!

So, I don't know if you already have resolved that bug or if you have something in your planning, but in case not (and if people feel hacky enough to mod their editor until an official fix appears), one could build a workaround by removing any occurence of \r in the pasted code or strip them from the split lines.

For the first method, the line I commented out in the snippet would do the trick. For the second method, one could add such snippet right after the split

for i, line in ipairs(lines) do
	local l = line:len()
	if line:sub(l, l) == "\r" then
		lines[i] = line:sub(1, l-1)
	end
end

I hope you'll find a more elegant solution than my monkeypatching and I hope that those pesky CRLFs were the only source for this specific bug. Have a nice day!

Thanks for the detailed report @Eiyeron -- this made it very easy to fix in 0.1.0e which is up now.

Glad to hear that and thanks for the quick update. Seems like it's fixed on my side too.