sublimehq / sublime_text

Issue tracker for Sublime Text
https://www.sublimetext.com
808 stars 39 forks source link

add option for Goto Anything to search by filename across panes #1768

Open timotheecour opened 7 years ago

timotheecour commented 7 years ago
huttarl commented 3 years ago

This feature request (considered a bug here: https://forum.sublimetext.com/t/goto-anything-go-to-open-file-in-a-different-group/2342/4) has been around since 2011. Also requested here:

I would consider it a bug too, since the name "Goto Anything" promises to eliminate the problem of knowing where to search, by searching across all boundaries. And yet it only searches within the current window.

Worse, the user who has tried "Goto Anything" and found that the file they're looking for doesn't show up in the list, may very reasonably conclude that the file is not open in SublimeText, even though it is (in another tab group / window). Therefore they may open it again, and start modifying it, not realizing that the first tab has its own unsaved modifications. Data may be lost.

I've tested this, and when saving the second tab with additional modifications to the file, there is no warning about the first tab and its modifications. If the user ever returns to the first tab (which may be much later, or never), there will be a warning that the file has changed on disk. At that point, there's a "reload from disk" option, but it's not obvious how to save the modifications from the first tab so that they don't get lost.

It would be much better for "Goto Anything" to list the already-open tab (in any window) in its list of choices, so that this problem doesn't arise in the first place.

Another good practice toward the same end would be that if a user opens a file, while that file is already open in a view somewhere, to prevent a silent duplication of views open on the same file: whether by just switching focus to that view (which could interfere with group organization), by moving the existing view to the current group, by asking the user what they want to do about the existing view, or at least warning them that the file is open elsewhere. However this is a separate issue from #1768.

sarev commented 7 months ago

Any news on this? It’s a something of a deal-breaker unless I can find a fix. I’ve just spent a couple of weeks transitioning from ST2 to ST4, with the million little jobs around porting custom plugins, macros, syntax highlights, keymaps, etc. and now I thought I was done only to find this find_in_files problem.

What’s the point of having view groups if I can’t have the find buffer in a different group to the file I’m working on, so I can see them side-by-side? If I move the buffer to a different group and double-click a search result, instead of moving to the matching line in the view I already have open (in a different group), I get a new view open in the same group where the find buffer is. So now I can’t see my find buffer any more.

This is a significant regression from ST2 in terms of general usability.

deathaxe commented 7 months ago

The functionality requested in OP is provided by Tab Filter plugin. It lists all open files of a window in a Quick Panel to quickly jump to.

This issue is however unrelated with how "Find in Files" is working or how it re-opens already open files.

sarev commented 7 months ago

Thanks for the clarification. Should I open a new thread for the find_in_files command behaviour?

deathaxe commented 7 months ago

If re-using open files/views in other groups is the only thing, it's probably not worth it as it seems fixed in ST4170+. If there are more issues about it, maybe yes. Haven't checked whether issues about it exist already, though.

sarev commented 7 months ago

OK. I can confirm my issue is fixed in the latest dev builds, so I'll stop wasting everyone's time. Many thanks for your patience!

jim-hart commented 6 months ago

I'm on ST4173 and I am still experiencing this issue.