> If I get some time, I could try and do this. Is anybody opposed to putting > the API docs in reStructuredText files and generating the API docs using > Sphinx? I've been using this for the Python bindings and it's quite nice > and easy, and there's support for C domain as well. >
I personally don't care, but being cautious, can you provide a C example? As we said in another thread there probably needs to be discussion on what is exposed of the Geany internal design, otherwise exposing it will freeze the design or cause plugin breakage (more than just re-compile) every time the Geany internals change. The second option isn't unual, for example the Linux kernal driver interface. Perhaps the call should go out to plugin developers, in general do they mind the disruption in return for more access to Geany capabilities? >> >>> Another thing that would be really helpful is to add something to the >>> doxygen comments like '@since' and to put the plugin API number when >>> that function/member/struct became available. >> >> I'm not sure about. The most interesting number is die Geany main >> version as you want to build something up to recent Geany version. >> However, I do understand your suggestion with API number and IIRC we >> had something like this under discussion earlier. >> Providing this information will allow plugin developers to make their plugin adapt somewhat to which Geany it is being compiled against. How would you show API and ABI info? IIRC the theory is that ABI changes don't require unchanged plugins to be recompiled (for example if a structure is extended) but API changes require at least recompile. But I am not sure it is working that way though? Cheers Lex _______________________________________________ Geany-devel mailing list [email protected] https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
