I presume you mean build_set_menu_item() and there the SETPTR() macro does the free.
Thanks, forgot to check the macro.
It can't be fire&forget since it has to monitor the command and restore the menu sensitivity when it finishes.
Sorry, I wasn't very precise. I meant fire&forget from the plugins perspective. It's logical that some kind of state information needs to be managed for the execution time of a command.
Yeah, you have to program everything that gets commands to know about it, the overloading order isn't straightforward, so its explicitly programmed, so a new source needs to be programmed in too, see for example get_next_build_cmd(). You also need to allocate the command array somewhere.
Hmmm...OK. Thought I could prevent that :-) I don't really like the close relationship of the build command GUI to the job/service of command execution. I guess I can only reserve some fixed memory for the ```GEANY_BCS_PLUGIN``` arrays at init time so that values can be filled in.
Probably the whole visibility of the build API could be revisited, for example if GeanyBuildCommand was available to plugins then they could manage the plugin source array themselves and so could set its size themselves. The Geany arrays are set at startup only from values in the config, and that wouldn't be terribly convenient to plugins.
Yes, I have implemented my own method for passing on global workbench commands to the single projects which simply works on the labels, not on the index/position. I only use the index/position of a command for the position in the popup menu. But the number of commands is not fixed. This doesn't fit to good to the current mechanism but I like it. I guess it is not very likely that the whole thing is being re-written so I maybe just let the user choose/enter a mapping to a build menu position.