Currently fails to build on Linux:

/src/blender/source/blender/editors/undo/ed_undo.c: In function ‘ed_undo_get_name’:
/src/blender/source/blender/editors/undo/ed_undo.c:483:12: error: returning ‘char (*)[128]’ from a function with incompatible return type ‘const char *’ [-Werror=incompatible-pointer-types]
  483 |     return &undo_stack->ui_undo_text;
      |            ^~~~~~~~~~~~~~~~~~~~~~~~~
/src/blender/source/blender/editors/undo/ed_undo.c:478:69: warning: unused parameter ‘ptr’ [-Wunused-parameter]
  478 | static const char *ed_undo_get_name(wmOperatorType *ot, PointerRNA *ptr)
      |                                                         ~~~~~~~~~~~~^~~
/src/blender/source/blender/editors/undo/ed_undo.c: In function ‘ed_redo_get_name’:
/src/blender/source/blender/editors/undo/ed_undo.c:539:12: error: returning ‘char (*)[128]’ from a function with incompatible return type ‘const char *’ [-Werror=incompatible-pointer-types]
  539 |     return &undo_stack->ui_redo_text;
      |            ^~~~~~~~~~~~~~~~~~~~~~~~~
/src/blender/source/blender/editors/undo/ed_undo.c:534:69: warning: unused parameter ‘ptr’ [-Wunused-parameter]
  534 | static const char *ed_redo_get_name(wmOperatorType *ot, PointerRNA *ptr)
      |                                                         ~~~~~~~~~~~~^~~
cc1: some warnings being treated as errors
[ 40%: -3] Building C object source/blender/editors/screen/CMakeFiles/bf_editor_screen.dir/screen_ops.c.o
FAILED: source/blender/editors/screen/CMakeFiles/bf_editor_screen.dir/screen_ops.c.o

/src/blender/source/blender/editors/screen/screen_ops.c: In function ‘repeat_last_get_name’:
/src/blender/source/blender/editors/screen/screen_ops.c:3695:12: error: returning ‘char (*)[128]’ from a function with incompatible return type ‘const char *’ [-Werror=incompatible-pointer-types]
 3695 |     return &wm->ui_repeat_text;
      |            ^~~~~~~~~~~~~~~~~~~
/src/blender/source/blender/editors/screen/screen_ops.c:3689:73: warning: unused parameter ‘ptr’ [-Wunused-parameter]
 3689 | static const char *repeat_last_get_name(wmOperatorType *ot, PointerRNA *ptr)
      |                                                             ~~~~~~~~~~~~^~~
/src/blender/source/blender/editors/screen/screen_ops.c: In function ‘redo_last_get_name’:
/src/blender/source/blender/editors/screen/screen_ops.c:3821:10: error: returning ‘char (*)[128]’ from a function with incompatible return type ‘const char *’ [-Werror=incompatible-pointer-types]
 3821 |   return &wm->ui_adjust_text;
      |          ^~~~~~~~~~~~~~~~~~~
/src/blender/source/blender/editors/screen/screen_ops.c:3801:55: warning: unused parameter ‘ot’ [-Wunused-parameter]
 3801 | static const char *redo_last_get_name(wmOperatorType *ot, PointerRNA *ptr)
      |                                       ~~~~~~~~~~~~~~~~^~
/src/blender/source/blender/editors/screen/screen_ops.c:3801:71: warning: unused parameter ‘ptr’ [-Wunused-parameter]
 3801 | static const char *redo_last_get_name(wmOperatorType *ot, PointerRNA *ptr)
      |                                                           ~~~~~~~~~~~~^~~

Indeed, for Rename it's not necessary to include the data block name. It could be added after any operator entry really, which indeed would be silly. Ie: Delete Suzanne, Duplicate Suzanne etc.

But, for Undo/Redo it really helps to include the operator. Users then know *what* they are undoing or redoing, which really helps. I would very much prefer if we could include the operator names in the Undo & Redo menu entries.

In D7414#178377, @Harley Acheson (harley) wrote:

none of the applications I checked do this, even for undo/redo (firefox/chrome/qt-creator/ms-word).

I can't see a reason for a web browser to need this. But my Word does have this:

From what I can see this is a history of actions, not a typical drop-down edit-menu with a fixed set of menu items.

Just to be clear, having more communicative Undo & Redo menu items is something most graphics apps do. I could mention them and post hundreds of screenshots, but will refrain from doing that here. We should remove the parts that include datablock names and only amend the Undo/Redo menus.

@William Reynish (billreynish) - We should remove the parts that include datablock names and only amend the Undo/Redo menus.

Current state of this patch no longer uses object name in Rename. It currently only changes undo, redo, adjust, and repeat. Although any dynamic changes to menu items would pose the same problems for things like “search from menu items” so I can understand that this idea could be a no-go. But always fun to explore.

The undo/redo menu items still contain the words undo and redo, so will still appear in the search.

The operator names should be removed from adjust and repeat I think, or they could simply be amended at the end so the full menu item text string is still searchable.

@William Reynish (billreynish) - The undo/redo menu items still contain the words undo and redo, so will still appear in the search.

My concern isn't really that they wouldn't be searchable. More that you would search for "undo" but then see "Undo Move".

It's all a matter of whether the new "search from menu items" is done in way that operatorType.get_name() is called. If the search results are going through that then we'll have problems with this and a few other operators that use it. If it is done in a way where get_name is bypassed then it would never contain dynamic info and all is fine. So searching for "undo" would show "undo".

Note that our overriding of the operator names, and the translations, do not go through get_name. get_name is only for the very few operators we have that dynamically change their own UI display names.

@Campbell Barton (campbellbarton) - Something like this:

Interesting. Thanks!

But if we assume that we never want dynamic content in the menu names for the search results, couldn't we just (somehow LOL) have WM_operatortype_name() NOT run get_name() if we are in a search? It seems like the only point of get_name is for dynamic names so it would make sense to not allow that in this case. I'm guessing at the moment we couldn't search for operator "call_menu" for example.

Or perhaps I'm just not thinking about this correctly.

In D7414#179091, @Harley Acheson (harley) wrote:

@Campbell Barton (campbellbarton) - Something like this:

Interesting. Thanks!

But if we assume that we never want dynamic content in the menu names for the search results, couldn't we just (somehow LOL) have WM_operatortype_name() NOT run get_name() if we are in a search? It seems like the only point of get_name is for dynamic names so it would make sense to not allow that in this case. I'm guessing at the moment we couldn't search for operator "call_menu" for example.

As long as the name from get_name is created based on the operator properties (which the menu sets), this wont be a problem.