Not sure I agree that Github is bad for *development* discussions, for users, sure, the ML is likely to find the audience better, but most developers will also be githubians. Also github supports markup that mail doesn't. But anyway lets try mailing it in for this issue, and see how it goes.
But everybody, please DO NOT EDIT THE SUBJECT LINE IF ON THREAD some mail agents thread by subject, and DO NOT REPLY IF YOU WANT ANOTHER THREAD some mail agents thread by previous ID. We should not dictate what sort of mail agent people must use to contribute, please respect individual or enforced choices and follow this procedure (codebrainz this should go on the issue guidelines). I agree with the approach in general, but for some major items (about the process): > rather than endless discussions we let the code do a lot of the talking No, not yet, we need to agree what we are going to code. This is a major change to Geany's design, and it should be designed, not just jump into coding it. Geany suffers from too much "heres some code I made earlier". codebrainz, you clearly have some design in mind, please *describe* (not code) it to get the ball rolling. > Code reviews are always welcome but should be accompanied by the appropriate > patches/PRs/commits Too draconian. Just because someone has questions/doubts/misunderstandings about some proposed code or design doesn't mean they have the knowledge or time to immediately propose an alternative. If comments that don't have corrections/alternatives proposed are ignored, nobody will review. Using a branch is good, but, as PRs cannot be layered on PRs, what process do you suggest for corrections to be proposed? And how will alternatives be compared? More than one PR cannot be committed at the same time, and "first PR gets committed" is a bad recipe for new designs, the first is often the worst. Having later PRs have to revert previous PRs just makes them more complex and harder to review so better proposals tend to be rejected. On the requirements, not much to say, agree in principle. Minor comments/suggestions: > Allow plugins to provide syntax highlight. Probably sufficient for Geany to support "container lexers" and flick-pass it to plugins. But then the plugins probably have to have a way to define styles similar to how `highlightmappings.h` is used for included lexers. > Allow plugins to provide the symbols for the tagbar tree... Do you mean the symbols pane? Or do you mean to inject symbols into tagmanager so all existing functionality also sees them? > provide the auto-complete list, given the current location in the document > and the part of the word already typed. Location in document is probably enough, the plugin probably has to check for preceeding context `aaa.bbb.ccc` anyway, so the partially typed name is no issue, and it can then be language specific, like lisp can include *s and -s and other things that C doesn't allow in names. > plugins to hook into the build system runner Plugins can now get and set any build command, not sure what else is needed, except maybe a way of telling Geany to not save the plugin set values, since the plugin is handling them. > plugins to provide diagnostics when build commands are run. Allowing the plugin to parse the command response *before* it goes in the message window would be good. General: I used to have a prototype of a change to load filetype specific plugins specified in the filetype file. I can't find it now (backups, whats that?) but it actually was so simple that it doesn't matter. Finally despite some disagreements on detail, the general idea and process is good (IMNSHO), thanks to codebrainz for starting the process. Cheers Lex _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel