Having support for prefix in header would not prevent one from leaving prefix empty, and still writing all of it to individual values.
This was something I'd been thinking of from the start (but left out for the sake of minimal initial implementation). The only reservation I have about this is that when searching source files (e.g. git grep or just searching on github) for one of the enum constants, right now you'd still find the corresponding line in the .def at least; if we change this, then once the generated headers are no longer checked into git, you wouldn't be able to find the definition at all if you don't already know where to look.
Then again, the same is already true for all the auxiliary functions; and you would still be able to find the name of the enum type itself.
Attached patch. Using the prefix is optional, so it's backwards compatible with other enums converted to the new format in the interim (e.g. #48785).
I don't like that this now leads to writing count COUNT a bunch; will make a follow-up for that.
Reply To alienvalkyrie
I don't like that this now leads to writing count COUNT a bunch; will make a follow-up for that.
~> #48789
Currently each value in specenum generator .def file contains the prefix, e.g., MANUAL_SETTINGS, MANUAL_COMMANDS ...
Should we move the prefix to header part, and define values simply as SETTINGS, COMMANDS ... ?