Fix for issue #6084: Move Find items to different menu

[lkcampbell]

Fix for issue #6084: Move Find items to different menu.

Creates a new Search Find menu.

Moves appropriate Edit menu items over to new Search Find menu.

Adds a new Search Find menu item "Find in Selected File/Folder". It is connected to the same command as the Project panel context menu "Find in..." menu item.

[peterflynn]

Changing the command constants could break extensions. We should search to see if any are using the old ones -- might want to consider keeping them around as deprecated if so.

[peterflynn]

Fwiw btw, I've never really liked the idea that we're prefixing everything with its menu parent's name. While we're renaming these, maybe we should just strip the prefix off altogether? (On the symbolic constants, not necessarily the underlying string values).

[njx]

Yup, I'd agree with that - the command names/ids shouldn't really depend on the location of the command/id in the menus (especially since we refer to these from unit tests, etc. - you shouldn't have had to change all that code just to move stuff to a new menu :)). We should've thought of that way back at the beginning :), but c'est la vie.

[TomMalbran]

I agree, we should replace the prefixes of all the strings with COMMAND or similar just to know that these are command strings.

[lkcampbell]

It looks like we use CMD_ as the prefix for the Command Name strings. Would it be good to use that prefix on the command constants as well?

For example:
CommandManager.register(Strings.CMD_FIND, Commands.CMD_FIND, _launchFind);

Has a nice symmetry to it, what do you think?

[lkcampbell]

The grabber keeps failing to unzip edge-inspect-extension and that causes the tool to fail. I am only able to get about 50 extensions before the failure. I can try to fix the error.

[njx]

Yeah, that's the kind of thing I was running into. I tried debugging it for awhile and wasn't able to find the cause of the problem. If you can figure it out that would be great, but I wouldn't rathole on it.

I just did a grep on the set of extensions I'd downloaded as of a few weeks ago, and I did find a couple that were referring to the EDIT_REPLACE_COMMANDS menu group in order to add their menu commands after it. So the issue is renaming that would throw an exception, but even if we kept the old const name around as well, it still would get added at the end of the menu anyway. That might be better behavior than just breaking, though.

I think we probably only need to worry about doing it for the menu groups, since those are probably the only cases where someone is referencing the existing IDs. It doesn't look like anyone is calling the commands themselves directly. We should add this to the release notes though.

[lkcampbell]

@njx, it's okay, I just hacked around the few that failed and grabbed them manually. I will compare my grep check to yours and supply the deprecation code in my next PR.

[lkcampbell]

@njx, I found the same two you found plus an additional one that uses Commands.EDIT_FIND. Overall, not too bad. I will create some deprecation code, load up the extensions to make sure it works, and post issues for the extension authors.

[TomMalbran]

Since we are changing some of the Commands constant, we should just go and change all of them. Then we can use the same deprecation code for all.

[njx]

Review done, just a couple of comments. The more I think about it the more I think we should rename it to "Find" - @JeffryBooher had raised the concern that these are usually in the Edit menu in Windows apps, and so moving them to another menu might impede discoverability, but if we name the menu Find I think it will be very obvious where those menu items are :)

[larz0]

+1 for "Find"

[JeffryBooher]

Mostly Muscle Memory. For many years I didn't use Ctrl+F or Ctrl+H to search/replace I would Alt+E>F or Alt+E>R. I may be the only one in the world who did that or maybe not. I still find myself doing it on occasion plus that's the place where most folks look. It's also in the Windows Style Guide for Application Interface design.

[njx]

I took a look at a few apps on Windows. It looks like most modern Office apps no longer have an Edit menu, although they do have special support for the Alt+E shortcuts (a little toast pops up saying something like "Continue typing the menu key sequence from an earlier version of Office"). I also checked Notepad++, which I think is one of the most popular text editors on Windows, and they also have all the find items in a separate Search menu (and it doesn't support Alt+E, F and the like). Looking at the screenshots of Windows editors on http://sixrevisions.com/web-development/the-15-most-popular-text-editors-for-developers/, it looks like many if not most of those apps have a separate Search menu too. So I think we're on ok ground here.

[JeffryBooher]

I think it's fine. Our Edit menu is getting quite large so this makes for a logical split. FWIW -- Visual Studio and Notepad carry on the tradition of Edit > Find in the modern age...

[lkcampbell]

@njx, reviewed your review. I have a few follow up questions posted above.

[lkcampbell]

@njx or @TomMalbran, code review changes committed.

The deprecation code should prevent the three affected extensions from blowing up.

I am going to post issues for the extension authors as well.

[lkcampbell]

@TomMalbran, I saw your brief comment and it brings up an interesting point I want to discuss.

I can understand how to show a deprecation warning in an invoked function. You just throw the warning in the body of the function. I am less clear on how to show a deprecation warning when a deprecated data member is accessed. Maybe the new Getter functions?

At any rate, my solution was to look at how the three extension authors used the constants and, in two cases, put my deprecation warning in the member function, addMenuItem(), that they were invoking. In the third case, the extension is assigning the constant to an object property:

{
  id:         ISEARCH_FORWARD,
  name:       "ISearch Forward",
  key:        "Ctrl-S",
  overrideId: Commands.EDIT_FIND
}

Not sure where to put the deprecation warning function in this scenario so I just pointed the old constant values to legitimate new values and posted an issue for the extension author.

[TomMalbran]

I am think that a getter might be the only way, and would work for all the cases. But we never had to implement it, so not sure what would be the policy about adding it?

Are we going to change more commands constants? The same issue could reappear if we split the Edit menu again in the future.

[lkcampbell]

@TomMalbran I agree. At the very least, we are probably going to create a Selection menu pretty soon. The poor Edit menu is getting clobbered with menu items from the native code and extensions. It is having a noticeable effect on the non-scrolling Linux HTML menus: #7496.

It would be nice to have a way to deprecate data members as well and I think getter functions are the only way to do it. I know @njx is not currently available but maybe we can get some opinions from some other core team members: @redmunds @peterflynn.

[redmunds]

We're just deprecating values, not a data member, so I think this is ok. If we plan to rename many more, then maybe just add a function to keep the code more isolated.

[lkcampbell]

@TomMalbran, my schedule is starting to change this week so I don't think I have the time to take on changing all of the constants. I have already talked to the one guy who is affected by the deprecation of the Edit menu constant values that were moved to the Find menu, so let's just get this PR done for now.

[lkcampbell]

I filed #7556 to document our discussion of the menu prefix problem.

[njx]

FWIW I think you should be able to deprecate the constants using the same trick we're doing for global CodeMirror, using a getter as @TomMalbran suggested: https://github.com/adobe/brackets/blob/master/src/brackets.js#L112

[marcelgerber]

@lkcampbell @njx I just wrote a getter ready to use and as general as possible:
marcelgerber@6c6371d

[lkcampbell]

@njx, ready for the next code review.

[njx]

Cool - I will probably get back to this tomorrow (Wed).

[marcelgerber]

Maybe remove the trailing period - it's sometimes confusing when you stare at an object notation

[lkcampbell]

Done.

[njx]

@lkcampbell Re-reviewed - just a few small notes and this is ready to go. Thanks again for doing this.

[lkcampbell]

@njx, Code Review changes committed. One question on the merge conflict for you posted above.

[njx]

Looks good (except for the possible merge issue above - will double-check after merging). Thanks for doing this!

[lkcampbell]

@njx, yeah, everything looks fine on my end as well. I ran the test suite and reviewed the specific code where the conflict occurred just to make sure, and everything appears to be as I expect it to be.