[CLOSED] Fix for issue #6084: Move Find items to different menu #6744
Comments
|
Review done, just a couple of comments. The more I think about it the more I think we should rename it to "Find" - |
|
+1 for "Find" |
|
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. |
|
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. |
|
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... |
|
|
|
The deprecation code should prevent the three affected extensions from blowing up. I am going to post issues for the extension authors as well. |
|
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, {
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. |
|
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. |
|
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 |
|
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. |
|
|
|
I filed adobe/brackets#7556 to document our discussion of the menu prefix problem. |
|
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 |
|
|
|
|
|
Cool - I will probably get back to this tomorrow (Wed). |
|
|
|
|
|
Looks good (except for the possible merge issue above - will double-check after merging). Thanks for doing this! |
|
|
Friday Apr 11, 2014 at 17:39 GMT
Originally opened as adobe/brackets#7488
Fix for issue #6084: Move Find items to different menu.
Creates a new
SearchFind menu.Moves appropriate Edit menu items over to new
SearchFind menu.Adds a new
SearchFind menu item "Find in Selected File/Folder". It is connected to the same command as the Project panel context menu "Find in..." menu item.lkcampbell included the following code: https://github.com/adobe/brackets/pull/7488/commits
The text was updated successfully, but these errors were encountered: