Find In Files/Next Result/Build should use sublime.Regions to mark results

[canoeberry]

When I use Find in Files and use Next Result and Previous Result commands to move around, the position is wrong if I make edits along the way. So, for example, if I go to the first occurrence in the file and fix a compilation error or change around some code, when I go to the next instance in that same file, the line numbers are all off. This gets progressively worse the further down a file I go.

A simple solution to this problem is to use sublime.Region objects for each match. You can still lazy load them when the file is first loaded (although Sublime is so freaky fast that probably doesn’t matter) but the nice part is, these markers continue to represent the actual location in the buffer in the face of any editing that occurs before you get to that result.

[FichteFoll]

When should the markers be cleared? Upon the next build attempt? Will there need to be an additional command for clearing the markers?

In other news, you should probably be using a linter plugin to more accurately reflect errors in your current code base (e.g. SublimeLinter).

[canoeberry]

The next time you run a Find Results is when the existing markers should be cleared.

This is not a linting problem. I’ve just grepped my code for something that I need to change in every place I use that pattern, and I just want the line numbers to stay in place as I make edits.

Emacs has been doing this forever and not having it is amazingly annoying. Perhaps I can implement this myself on top of the find in files command. I am not sure how that all works, whether it is a synchronous command or not, it just seems more easily done inside the built-in find in files command.

[kingkeith]

Another alternative workaround would be to start making changes at the last search result and make your way up the list/document instead of down - that way the locations of the not-yet-changed results will still be correct.