[UX] Move Find items to different menu?

[VizuaaLOG]

I noticed that find, find in files, find next and find previous are located in the edit menu. However, shouldn't it be in navigate because you are navigation the document for the inserted text?

If I'm wrong then sure but if not I could easily move the four items.

[peterflynn]

I believe it's a common convention on both Mac & Win to place Find-related menu items in the Edit menu -- unless there's specifically a Search menu, which we don't (yet) have. Is there an editor you're familiar with where search options are under Navigate instead of Edit?

[TomMalbran]

I think we should have a Search menu. The edit menu is getting long and lots of extensions add items there. I was planning on adding a Search menu in my Find in Files request (which also added a few extra commands). I might do it later as a separate request to start some discussion about it.

[VizuaaLOG]

@peterflynn No the other editor i use, notepad++, has it located under a search menu. I just though it would have more sense being under navigate.

[peterflynn]

Clarified title (was: "Find in Wrong Place")

[marcelgerber]

I checked back Notepad++ and SciTE. Both got own Search menus.
And notepad.exe (default Windows editor) got Search/Replace entries in the Edit menu (as Brackets currently does).

[njx]

Ultimately, we also want to have submenus, which would decrease the size of the Edit menu substantially (though I don't think we would move the Find items to a submenu, we would likely group some of the other less important commands into submenus). That might be a better solution.

Before deciding to move the Find items to a separate menu, I think we should figure out whether we're planning to do submenus anytime soon. See https://trello.com/c/EwLGRkYe/541-native-submenus and https://trello.com/c/OrIaeTsS/505-5-html-submenus.

Pinging @larz0 and @jadbox for opinions. Jonathan, do you think it's likely we would get to submenus soon? (We've wanted them in general for quite awhile since our menus are getting pretty long.) Larz, even if we had submenus, do you think we should consider adding a separate top level menu for search? (I'm not sure how many other search commands we would be likely to add over time.)

Tagging needs review to revisit once we've gotten Larz and Jonathan to weigh in.

[TomMalbran]

Besides the 5 search commands we currently have, I can think of 5 new commands that would be useful and even adding the "Find in ..." command as "Find in Selected File/Folder" to this new menu. One of the new commands would be a "Find in Working Set" and the 4 others would be to navigate through the Find in Files results, the commands mentioned here. 10 commands is a good number for a new Search menu.

The submenus would allow us to group the navigation commands, since I think that the main Find commands should be accessed from the main menu, which would reduce the size of the menu, but I find that a Search menu can be a better idea.

[njx]

I think it's likely that some of those commands would be unified into a single UI rather than having separate commands for all of them. But @larz0 and @peterflynn will be considering these issues as part of the upcoming find/replace revamp, so suggestions are welcome.

[TomMalbran]

Do you mean something like letting us select the scope for Find in Files in the search modal bar? This would mean that we can use just one command for all the Find in Files actions. Same with Find and Replace if they get unified. So we could end with just 2 main commands an a bunch of navigation commands that could end inside 1 or 2 submenus. That would work good too.

[njx]

To @larz0 to consider. Some mitigating factors: we'll have submenus in the future, which will make it easier for us to shorten the Edit menu by collapsing some of the other items in the menu together; we might not want more top-level menus. OTOH, many other editors have a separate top-level menu.

Larz, if you have any thoughts, make a recommendation and we can add a user story or roll it into one of the existing find/replace stories.

[larz0]

@njx if there's a substantial amount of items for Find/Replace then we should have a Find item on the top level.

E.g.

[larz0]

Reviewed.

[njx]

@larz0 If you unassign yourself from a bug, could you either assign it to someone on the dev team or set it to "needs review"? That way bugs don't start to slip through the cracks. Thanks.

[larz0]

Ok got it.

[njx]

Thanks @larz0. Since we only have 5 items right now, it doesn't seem necessary to make a separate menu (it's true that our Edit menu is long, but that's really because of the lack of submenus, which we really need to get to). We'll close this for now and just keep in mind that if we add significantly more find-related items we should create a separate menu.

[TomMalbran]

@njx @larz0 Now that we have 8 find items in the edit menu, I think it will be a good time to split it. The edit menu is really long with the new multiple cursor commands.

It can be even longer if we add this commands to the menu, and/or add the find in subtree command and new ones to come.

[larz0]

@TomMalbran @njx sounds good.

[TomMalbran]

Cool, I'll do it :)

[larz0]

Awesome. Best Einstein's b'day present ever.

[marcelgerber]

@TomMalbran @larz0 Another idea would be to add a new "Selection" menu.

[TomMalbran]

@SAplayer That might work too, it might depend on which new multiple selection commands we consider that should go in the Selection menu or in the Search one. At this point I don't think that we need both new menus.

For search it can be:

Find
Find Next
Find Previous
Find All and Select
Add Next Match to Selection
Skip and Add Next Match
---
Find in Files
Find in Selected File/Folder
---
Replace

Plus more commands to come later, like Find in Working Set, Find Next in Files, Find Prev in Files, and maybe others, depending if we want to add those commands to the menu.

For Selections it can be:

Select All
Select Line
Split Selection into Lines
Add Next Line to Selection
Add Previous Line to Selection
---
Add Next Match to Selection
Skip and Add Next Match

And maybe others that we might want to add.

[lkcampbell]

@njx and @larz0, if you guys want me to take this issue over I do have a little free time now to do a PR. Let me know either way.

I think @TomMalbran's suggested menu structure looks pretty good. The only change I suggest is calling the Menu Find instead of Search. The majority of the commands in the menu start with the word "Find" and, also, that's the term that Sublime uses for its menu.

I could also make a Selection menu as well as presented above. Sublime also has a Selection menu. Technically, Undo/Redo Selection could be in Edit or in Selection, I suppose.

At any rate, let me know if you want me to do one, both, or none of these top level menus. Also, if the proposed structures look good or if you want the structures to change.

[njx]

I think just doing the Find menu items would be good for now. I'm a tad hesitant to introduce two new top-level menus :)

[lkcampbell]

@njx, sounds good. People can follow up on the structure and the strings in the PR. Reopening and assigning to myself.

[lkcampbell]

@TomMalbran, Find in Selected File/Folder is something for the future correct? Not part of these changes yet.

[marcelgerber]

@lkcampbell It's currently in file tree context menu only, not in the Find menu. But AFAIK, you can easily add the command to the new menu without big changes.

[lkcampbell]

Okay, I understand. A couple of design questions on this:

1. Should the menu item be disabled when there are no selections or when the selection is a binary image file? In other words, when there is no code editor? Actually, most of our menu items that should disable in these conditions do not currently disable. Maybe this is a broader menu design question.
2. When you write Find in Selected File/Folder, do you mean the literal string File/Folder or do you mean it changes to either File or Folder depending on which type is selected?

[lkcampbell]

Regarding my previous design questions, we can disregard number 1 for this specific functionality. When you select Find in Selected File/Folder from the main menu when there are no files open, it just does a search on the project, which is a great default. I'm not sure how we got this functionality automatically, must just be some good defensive coding in the command.

I do still think the enabled state of the menu items when no main code editor exists is something worth investigating.

For number 2, I am keeping the string literal for now. It's the simplest solution. Posting the PR momentarily with @TomMalbran's original design. Menu will be called Search. Structure per #6084 (comment).

[TomMalbran]

Yes, Find in Selected File/Folder is the current Find in... from the context menu, but adding it in the Find menu might make it easier to find. I wasn't planning any fancy for this menu, so yes I was thinking of adding it with that name. But it could change depending on the selection.

Currently the Edit menu items are not disabled when there is no editor, or when the editor is a custom view. But we could fix that, probably in another PR.

I am ok with calling it Find, but Search might work better as the prefix, since we dont get someething like FIND_FIND_... in the keys.

[lkcampbell]

@TomMalbran, yes I noticed that FIND_FIND issue when I started writing the code. That's what changed my mind back to Search :).

Per the discussion of the enabled state of Commands and Menus when no code editor in present, I filed issue #7490.

[njx]

Fixed in master by moving these commands to a new Find menu (thanks @lkcampbell). Closing - @VizuaaLOG, please check this in the next release.