bug#58406: 29.0.50; Bars refactoring?

[Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Manuel Giraud <manuel@ledu-giraud.fr> writes:

> I'm trying to have some kind of highlight feature on the no-toolkit menu
> bar.  As this feature is already present in tool/tab bar, I'd like to
> mimic those.

What kind of highlight?

> +enum bar_type
> +  {
> +    MENU_BAR,
> +    TAB_BAR,
> +    TOOL_BAR
> +  };

These enums are definitely named too generally.  They could conflict
with other libraries down the road.

> +/* Get information about the bar item which is displayed in GLYPH on
> +   frame F.  Return in *PROP_IDX the index where bar item properties
> +   start in the bar items.  For TAB_BAR, return in CLOSE_P an
> +   indication whether the click was on the close-tab icon of the tab.
> +   Value is false if GLYPH doesn't display a bar item.  */
> +
> +static bool
> +bar_item_info (ENUM_BF(bar_type) bar, struct frame *f, struct glyph *glyph,
> +	       int *prop_idx, bool *close_p)

Why ENUM_BF?

BTW, I really don't recommend doing this kind of refactoring so close to
cutting the Emacs 29 branch.  Last year I and Alan Third found and fixed
several obscure bugs related to the tab bar code being a poor cargo cult
of the tool bar code, introducing subtle differences between both pieces
of code.  Any refactoring there is likely to introduce more bugs, or to
reintroduce old ones, and those bugs are much too subtle to find before
November (or even February.)