Paste Bug

Bugs
1

I’ve encountered a number of bugs related to either Paste or Replace All, but I’m trying to isolate them before reporting them.

The one I’ve figured out now is that if one pastes in text (I sometimes convert C code to lua on my Mac, using a more reliable/powerful editor, then paste it into Codea) the paste operation detects keywords like “function” or “if” which are within comments and starts indenting as if they were code. The result, especially for a large class file, becomes layers and layers of progressively worse/wrong indentation:

Function this() print(“hi”) end
—[[ Did you like that function? ]]
Function that() print(“oh no”) end
—[[ Wait, what if I don’t like that? ]]
Function what() print(“not again!!!”) end

2

FYI, the above text doesn’t cause the problem. It only happens on multi-line comments:

function this() print(“hi”) end
–[[ Did you
like that function? ]]
function that() print(“oh no”) end
–[[ Wait, what
if I don’t like that? ]]
function what() print(“not again!!!”) end

3

@blacatena The rem commands for blocks involves --[[. And --]] so your second lot of square brackets in each case is not correct ie the ]].

function this() print(“hi”) end
--[[ Did you
like that function? 
--]]
function that() print(“oh no”) end
--[[ Wait, what
if I don’t like that? 
--]]
function what() print(“not again!!!”) end

Try the above, still might crash but worth a try.

Note - formatting when I am posting this by phone rarely works. The ~~~ characters don’t seem to work. Android phone - anyone any idea how to fix that?

4

@blacatena interesting bug, I can see how that might happen. To fix this behaviour could you try use the “Edit → Paste without formatting” option in the editor’s Edit menu.

If you want to permanently change this behaviour you can disable the “Format on Paste” option in the Editor Configuration. (Open the right setting panel on the main screen and choose “Editor Configuration” then disable “Format on Paste”)

What’s happening is that Codea doesn’t immediately recognise multiline comments, so it thinks the internal code is actual code that needs indentation and attempts to indent the code prior to recognising the multiline comment. The “Paste without formatting” action might be the way to go for now, but I’ve noted this as something to look at fixing

5

@Bri_G

Actually, no, you’re incorrect. I find it good practice to end a comment with —]], because then one can safely comment out and later uncomment a block of code. Much of the documentation says what you believe (and maybe they actually “fixed” it in later interpreters to make ]] illegal for closing a long comment, although I can’t find an interpreter that enforces that), but the syntax —[[ comment ]] is correct.

The double-dashes initiate the comment. The “long bracket” (double open square brackets) after the double-dashes initiates a long string as the content of the comment. As with non-comment long-strings, the closing long bracket terminates the string, and therefore the comment. Any double-dashes encountered before the closing long bracket are actually part of the comment!

For fun, try adding ]] in the middle of a long comment, and see what happens!

You can try it in Codea, or on CodeRunner on the Mac, or at:

https://www.lua.org/cgi-bin/demo

6

Simeon, thanks! Your solution makes perfect sense (although I see no “Paste without formatting” option in the Edit menu, disabling it permanently works better for me anyway).

I wonder if formatting is also behind the other nasty bug that I can’t pin down (so maybe there’s more than one bug). A Find/Replace will often destroy code on a Replace All or even a few manual replacements within a single Find. What looks like is happening is that the Find is gathering text-location pointers when it first runs, but when Replace changes the text, the pointers aren’t updated so a subsequent replacement will replace the wrong characters.

[One clue to that is that the destruction doesn’t seem to happen if the replacement string is the same length as the search string.]

Sometimes, Replace All also skips instances of found text (doesn’t replace them).

That’s not the entire problem, and might be a red-herring… and I swear I’ve seen both replace and paste actually move lines (i.e. swap their positions).

But either way, I never, ever use Replace All and I am super careful about using Replace. More than once I’ve wasted hours recovering code that was brutally mangled by it.

I wish I could give you more details, but you might look into some connection between either pointers that become stale with each replacement, formatting-during-replace, or both.

Also… undo won’t work after Replace makes a mistake. Sometimes the undo even makes things worse.

Try finding and replacing “test” in the following text with XYZ (shorter), 012345 (longer), or “same” (same length) to see where it skips instances of “test” and where it makes replacement mistakes, and how Undo behaves afterward. FYI, this sample text purposely avoids using Lua keywords, to avoid the formatting complications.

–[[
I like to test things
This is a test
test file
test file
there is no question
there is no answer
Tetse not testable
there is no answer here
This test will succeed
This test may fail
]]

7

@Bri_G. I just realized that you referred to comments as a “rem command”. I thought I was the only person left alive who first learned to program in BASIC (in 1972!).

8

@blacatena - thanks for the feedback, tried out what you suggested and it worked fine. Your point about the --]] arrangement makes sense so I will probably stick with it - but now appreciating why. Yeah, learned basic on a mainframe teletype about the same time as you so tend to think of comments as REM statements - small world, getting even smaller by the day.

9

@blacatena would you be willing to try the beta? I’ve been auditing the code around text editing and made some big changes internally. I’d like to know if find/replace works better for you

If so, please DM me your email and I’ll invite you to TestFlight

10

@Bri_G Teletype, yes (the type I used is in the picture), and my first programs were in fact stored on paper tape (not even punched cards, although I used those, too)… something most people probably don’t even realize ever existed.

11

@blacatena - that’s just like the one I used, round tubular keys. With a paper tape puncher and tape writer/reader. Connected to a mainframe 25 miles away. Running a small program which you could do on programmable calculators nowadays. Revolutionised our work.