Menu
▾
▴
#226 Replace Alll on Very Large File Executes Save
I have a very large XML document, about 6.5 MB, extracted from a corruped Word document. Performing a moderately complex RegEx search and replace takes a very long time. That is unsurprising, but it also performs a save before it completes the Replace All operation. This is highly annoying because Undo does not work after the document is saved. Therefore there is no way to restore the unedited document.
After noticing this problem, I created a new document and filled it with many paragraphs of the same text (about 100,000 lines). Long-running Replace All operations still performed the save.
Another problem I noticed with the first document is that the Replace All operation often failed silently and simply deleted all but the first 25,000 lines or so. Of course, this deletion was also saved to disk. I have not been able to replicate this issue with the new document.
Related
Hi John,
I can't reproduce this. I tried with a very big XML file (more than 100000 lines) and everything happened as expected. Could you describe exactly the steps you are taking ?
Hi Bernard,
Thank you for looking into this issue. As you can imagine, it has been a while since I submitted this report, so my life has moved on. However, I do recall the problem and I was able to reproduce it. at least the part about saving prematurely. As it turns out this issue is caused by the Auto Save on Switch preference setting. When the operation runs on for a long time, I tend to go do something else. The save happens the next time the application is idle, not when the switch happens.
In case it is helpful, here are the steps I followed.
I created a new document in AlphaCocoa.
I typed “This is a test, ” (Note the comma instead of a period.)
I selected the whole text using Command-A and copied the text to the clipboard.
I pressed Command-V 36 times to create a paragraph of reasonable length.
I pressed Return.
I selected all again and copied the paragraph to the clipboard.
I pressed Command-V 49 times to give me 50 paragraphs (50 lines) of text.
I selected all and copied to increase the size of the clipboard.
I pressed Command-V 19 more times to get it up to 1,000 lines.
Select all, copy and past nine more times got me to 10,000 lines. Finally, I repeated that one more time to get to 100,000 lines.
I saved the document and made a copy of it on the desktop.
I pressed Command-F and put “,” in the Find What field and “.” in the Replace field (without the quotation marks) and pressed Replace All. As expected, this operation ran for a while (about 40 seconds, now that I’m counting). The little dot appeared in the window’s red close button. If I do nothing else with the computer, both while the operation is running and after it is finished, the dot remains and the operation can be undone with Command-Z. I can also make selections and type after the operation is complete and the document is not saved. However, as soon as I click to another application, the dot in the close button goes away, the document is saved and undo is no longer available in the Edit menu.
Now that I’m playing with it, I think this is a “feature” not a bug. It seems that Alpha saves any unsaved document that has a file associated with it each time I leave the application. I have never noticed this before, but I just tried it with a document that had just a single word in it. I made a small change by typing and switched to another application. Sure enough, the document was saved and I was unable to undo that typing. I’m sure this is very helpful for some people, but (given that a save clears the undo stack) I find it very annoying. I will save when I want the document saved. There are times when I want to be able to make changes and know that the document will not be saved because I need the disk version to be different from the memory version.
Is there a setting somewhere for this? Yes! There is! I must have turned on Auto Save on Switch at some point and forgotten about it. I will turn that off! That setting has restored my ability to run a long replace all without worrying about it being saved.
One time when I was doing this testing, the Replace All operation did not seem to fire correctly. Right after I pressed Replace All in the Find dialog box, the mouse pointer stayed as an I-beam instead of switching to the spinning beachball. I did nothing and it stayed that way for at least 90 seconds, twice what I had come to expect. I then tried selecting some text to see if the application was responding. It did not select the text I selected, but did select a single character near where I started the selection. It then switched to the beachball and spun for some time. It then seemed stuck in a mode where it would give me an I-beam, but would not reliably select text or do anything else. I would try to select and it would give me the beachball. Then it would select at least some of the text I had covered with the mouse gesture and then go back to the beachball, sometimes in several steps. That went on for about five minutes and then I came over to my email client to write this paragraph. When I was done, it was still stuck in that mode. The same would happen if I used the arrow keys and shift key to move the cursor and make selections. I eventually closed the window with Command-W and reopened it with a double click in the Finder. That seemed to restore normal operations, but that went on for at least ten minutes. Alpha never saved the document during this time.
I was not able to reproduce the problem of everything being deleted after the first 25,000 lines or so. I imagine that happened when my RE search was more complex that I’m doing. I’ll have to wait until I need to do that again to diagnose this problem. I tried a slightly more complete RE search (replace each sixth instance of a comma with a period, but that did not cause any problems.
Best,
John
Related
Tickets:
#226Hi John,
thank you for the input and the detailed explanations. The original problem was finally normal behavior since the Autosave On Switch feature was turned on on your machine. I'll resolve this ticket as fixed now.
The other experiment you describe can be due to a very intensive regexp which requires a lot of calculations during which the application from time to time peeks in the main event loop and handles your mouse events. Just a blind guess...