4 ms·
I stopped using Atom after I ran into this issue:[0] Basically it's possible to accidentally do a mass replace of a word you did not intend to. In sublime, if
by swang 11y ago
I stopped using Atom after I ran into this issue:[0]
Basically it's possible to accidentally do a mass replace of a word you did not intend to. In sublime, if you do a mass find/replace, it doesn't save the file. However by default atom saves all the files you make a find/replace in. So you could lose a lot of time undoing an accidental replace. Given my habits (listed in the issue) while in a text editor, this was unacceptable risk for using atom, so of course I filed a ticket which promptly died out.
I would like to continue using atom, even with the latency startup issue, but there's too much risk for me in accidentally wasting a lot of time getting bit by this issue.
[0]https://github.com/atom/find-and-replace/issues/550 https://github.com/atom/find-and-replace/issues/550
- adrianN 11y agoI agree that this is an annoying issue, but doesn't your version control take care about undoing things like that?
- swang 11y agoGenerally yes. Basically there are a lot of ways to mitigate the problem this causes, but atom could just do what every other editor does and not add this risk into my workflow.
- notalaser 11y agoWell, I mean technically, your version control could take care of it even after the editor would save the file after every keystroke. "Ooops, I didn't mean to do that" is one of the primary reasons why "Undo" was invented. It's something that should be fixed in the editor, not offloaded to the version control system, especially since there's no reason to assume that every single plain text file you'll ever edit is under version control.
- dragandj 11y agoOnly if you stash every single keystroke.
- Matt3o12_ 11y agoI don't really use version control for text because it is often pointless (how helpful are one or two commits when I will never touch the text again after getting graded). And yet I still use More tradition text ediots for that (WYSIWYG editors can get really annoying). Though i personal vim over atom but that is not the point. The point is that undoing things is really important. I've also often been in a position where I do big commits that contain about 200 lines of code and messed up by using replace/etc in the wrong way
- yAnonymous 11y agoYou can add files to the index before doing find/replace and then go back to that if something goes wrong. When you only add files to the index right before you commit, you are wasting a lot of your VCS' potential.
- Matt3o12_ 11y agoI sometimes do that for as a kind of backup, when there is a chance that something disastrous could happen but that requires that I use a version control system (which is pointless for text documents with less then 2000 Words IMO) or that I remember doing that. Because once I add files to the index, i might as well create a commit and squash it later.
- chr1 11y agoYou can change this with few lines of code in init script. That's the main selling point of Atom, ability to easily change any behavior annoying for you only, without recompiling whole thing.
- swang 11y agoHow would you do this to "fix" the Find/Replace module? Would I have to maintain my own fork of it for it to work?
- yAnonymous 11y ago1) Many users find the CTRL+F feature useful, because it saves time. 2) You can only use mass replace after doing a search first, so you can see what is going to be replaced. 3) You should look at the input before doing a find/replace. 4) Better use of version control would have made your problem a non-issue, even after 3). Both of these features enable you to get stuff done faster. It's only different, yet you're acting as if it's wrong. If you like the Sublime Text way more, keep using it. But please, don't act all entitled and try to make Atom exactly like Sublime Text in every way.
- stinos 11y agoyour points sure are valid, but they all miss the key point (at least for me and probably for the OP): they cost time.. People do not always want to bother going through all matches to see if they really want to replace them (for instance because the changes can be validated by the compiler/tests suite), let alone they want to first commit all current changes to their repo before doing a find/replace (if there even is a repo to begin with)
- yAnonymous 11y ago>People do not always want to bother going through all matches That's funny, because Sublime Text opens all currently not opened files with matches for you to review before saving them individually. Having all that in a single search window is definitely faster. Again, you cling to a single use case (having all files with matches already open) and demand changes, because you think your way of doing it is "right" when in fact there are many use cases that benefit from the way Atom currently handles find/replace.
- stinos 11y agoI don't think my way is the right one (for starters because I do not have just one way of doing things), I'm merely explaining why in some cases doing as you suggest is not wanted (ok, could have called it a keypoint instead of the keypoint to make this clear I guess). Also I'm not even mentioning Sublime/Atom here, just editors and find/replace in general.