Re: [Geany-Devel] [FT-plugins] Allowing plugins to supply filetype specific functionality
On 2016-08-26 09:17 PM, Lex Trotman wrote: [...] I just meant for that meta tracker issue. It gets too hard to keep track of what's going on when there's dozens and dozens of comments. I would expect code-related discussions to happen on the individual PRs or separate ML threads. I was thinking of the design discussion (see below) but I guess you could make another issue for that if you want #1195 to just be a management issue. Yeah, I propose the meta issue be used for tracking the overall progress and such, leaving hammering out design discussions to the ML and specific code discussions to their relevant PRs. 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). That was the idea with the subject tag, in case there's multiple threads any mail client or ML archive can be searched by that, at least. Yeah, but the mailers that thread on subject use the whole subject line, not just a tag, so the whole subject needs to be maintained. Yeah, I assumed that is the default for non-broken mail clients. 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 [...] I meant once we start implementing it, for the actual PRs. Like instead of saying "oh this is wrong" or "if you did it this way, ...", we could just provide a PR to fix it. Well, like I said, that assumes the commenter has the time and knowledge to do so, banning comments on the basis that the commenter hasn't provided an alternative doesn't sound like a good idea. My proposition is that people without time or knowledge not contribute to the development of this enhancement. Of course everyone would be able to comment on stuff as it is merged back into master, but only those willing to actively develop the solutions have any kind of strong voice during the actual development. But just to clarify, when you say "design", can you elaborate concretely on what that means to you? What exact steps/process would consider that once complete would mean the design is done? This is a genuine question, since "design" is a wafty term that means different things concretely to different people (UML diagrams, flow charts, UI mockups, long design documents, a wiki page, etc). Not this formal, see below. OK, so more like a wiki page describing the plan. codebrainz, you clearly have some design in mind, please *describe* (not code) it to get the ball rolling. I kind of did in the PR description, but will follow up with more specifics later. Thats what I mean, the sort of thing as discussed in IRC is a start, then API examples and examples of how the plugins would look in different languages (again as discussed on IRC). If you want to keep #1195 pristine, maybe you should copy the design stuff to another issue then. Probably opening specific Issues and linking back to #1195 would suffice. 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. As above, I just want to avoid the PRs getting bogged down with all kinds of minor comments. It's a morale buster. I'm guilty of this on many occasions myself, which is why I put that. Mostly I just want to replace a comment like "you should do ..." with "if you do it like this patch ..." or "I've submitted a PR which does that better". Basically the idea I have is that anyone who is interested enough in contributing should be willing to contribute code/patches/examples/etc where appropriate rather than only ever putting comments in a text box on a webpage. "Willing" and "able" are two different things. Yes, but I propose only those willing (interested in the improvement) and able (able to read and write C code and make patches/PRs against various forks/branches) should be included in at least the earlier stages. Of course it doesn't have to be hard and fast, and it's always useful to have a sharp eye pointing out fundamental issues, but it's counter-productive to debate which colour the bike shed should be while the structure is being built. Sure but many comments will be minor, and I don't think its a good use of either the commenter or the PR owners effort when you compare: 1) the time and effort required to make a comment "typo" and the OP making the change as they do other stuff vs 2) the comme
Re: [Geany-Devel] [FT-plugins] Allowing plugins to supply filetype specific functionality
[...] > I just meant for that meta tracker issue. It gets too hard to keep track of > what's going on when there's dozens and dozens of comments. I would expect > code-related discussions to happen on the individual PRs or separate ML > threads. I was thinking of the design discussion (see below) but I guess you could make another issue for that if you want #1195 to just be a management issue. > >> 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). >> > > That was the idea with the subject tag, in case there's multiple threads any > mail client or ML archive can be searched by that, at least. Yeah, but the mailers that thread on subject use the whole subject line, not just a tag, so the whole subject needs to be maintained. > >> 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 >> [...] > I meant once we start implementing it, for the actual PRs. Like instead of > saying "oh this is wrong" or "if you did it this way, ...", we could just > provide a PR to fix it. Well, like I said, that assumes the commenter has the time and knowledge to do so, banning comments on the basis that the commenter hasn't provided an alternative doesn't sound like a good idea. > > But just to clarify, when you say "design", can you elaborate concretely on > what that means to you? What exact steps/process would consider that once > complete would mean the design is done? This is a genuine question, since > "design" is a wafty term that means different things concretely to different > people (UML diagrams, flow charts, UI mockups, long design documents, a wiki > page, etc). Not this formal, see below. > >> codebrainz, you clearly have some design in mind, please *describe* >> (not code) it to get the ball rolling. >> > > I kind of did in the PR description, but will follow up with more specifics > later. Thats what I mean, the sort of thing as discussed in IRC is a start, then API examples and examples of how the plugins would look in different languages (again as discussed on IRC). If you want to keep #1195 pristine, maybe you should copy the design stuff to another issue then. > >>> 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. >> > > As above, I just want to avoid the PRs getting bogged down with all kinds of > minor comments. It's a morale buster. I'm guilty of this on many occasions > myself, which is why I put that. Mostly I just want to replace a comment > like "you should do ..." with "if you do it like this patch ..." or "I've > submitted a PR which does that better". Basically the idea I have is that > anyone who is interested enough in contributing should be willing to > contribute code/patches/examples/etc where appropriate rather than only ever > putting comments in a text box on a webpage. "Willing" and "able" are two different things. Sure but many comments will be minor, and I don't think its a good use of either the commenter or the PR owners effort when you compare: 1) the time and effort required to make a comment "typo" and the OP making the change as they do other stuff vs 2) the commenter making another PR and the OP having to then combine those. > [...] > You can submit PRs to people's PRs, it's easy. I didn't know you could do that, how? [...] >> 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. >> > > It might be better to provide some kind of interface for this if we go the > container lexer route to make it less crazy to implement. The dynamic lexer > way is perhaps more work, but it's also more structured and one can use all > of Scintilla's lexers as examples. Needs more research. Yes, don't know which is better. > >>> 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? >> > > I mean something more like where Geany tells the plugin it wants to update > the symbol tree and so asks the plugins for the symbols to show. It's > sounding (from Jiří
Re: [Geany-Devel] [FT-plugins] Allowing plugins to supply filetype specific functionality
On 2016-08-26 01:34 PM, Thomas Martitz wrote: Uhm, where did this thread start? Who are you replying to? My bad, I should've also sent a mail to the list. I assumed most of the main dev contributors got mail from Github about the Issue I posted, and anyone else would jump in as interested. [...] We want interfaces where plugins can provide [...] Without responding to specifics, I totally agree and I think we are on the same page WRT the mechanisms used to interface between Geany and the FT plugins (in the Issue I mention libpeas and gtksourceview providers as an example). Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] [FT-plugins] Allowing plugins to supply filetype specific functionality
On 2016-08-26 12:13 AM, Lex Trotman wrote: 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. I just meant for that meta tracker issue. It gets too hard to keep track of what's going on when there's dozens and dozens of comments. I would expect code-related discussions to happen on the individual PRs or separate ML threads. 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). That was the idea with the subject tag, in case there's multiple threads any mail client or ML archive can be searched by that, at least. 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". I meant once we start implementing it, for the actual PRs. Like instead of saying "oh this is wrong" or "if you did it this way, ...", we could just provide a PR to fix it. But just to clarify, when you say "design", can you elaborate concretely on what that means to you? What exact steps/process would consider that once complete would mean the design is done? This is a genuine question, since "design" is a wafty term that means different things concretely to different people (UML diagrams, flow charts, UI mockups, long design documents, a wiki page, etc). codebrainz, you clearly have some design in mind, please *describe* (not code) it to get the ball rolling. I kind of did in the PR description, but will follow up with more specifics later. 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. As above, I just want to avoid the PRs getting bogged down with all kinds of minor comments. It's a morale buster. I'm guilty of this on many occasions myself, which is why I put that. Mostly I just want to replace a comment like "you should do ..." with "if you do it like this patch ..." or "I've submitted a PR which does that better". Basically the idea I have is that anyone who is interested enough in contributing should be willing to contribute code/patches/examples/etc where appropriate rather than only ever putting comments in a text box on a webpage. 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. You can submit PRs to people's PRs, it's easy. Alternatively, just providing a patch (gist, by email, or even inline in comments) would work too. 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. It might be better to provide some kind of interface for this if we go the container lexer route to make it less crazy to implement. The dynamic lexer way is perhaps more work, but it's also more structured and one can use all of Scintilla's lexers as examples. Needs more research. 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? I mean something more like where Geany tells the plugin it wants to update the symbol tree and so asks the plugins for the symbols to show. It's sounding (from Jiří and Thomas) that using TM as a conveyance mechanism for this may make some sense. provide the auto-complete list, given the current location in the docu
Re: [Geany-Devel] [FT-plugins] Allowing plugins to supply filetype specific functionality
Thomas, #1195, maybe read that and try again. Cheers Lex On 27 August 2016 at 06:34, Thomas Martitz wrote: > Uhm, where did this thread start? Who are you replying to? > > > Am 26.08.2016 um 09:13 schrieb Lex Trotman: >> >> 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. > > > > I'm not even sure what the thread is about. Is it replacing ctags through > plugins or filetype specific plugins? The latter is much more than just > tags. > > For the former, I can only say that we must avoid trying to take shortcut by > adding APIs like "allow a plugin to add its own tags to the sidebar" or "add > words to the autocompletion dialog". This is use-case specific, and is going > to be troublesome if multiple, competing plugins are at play (not > necessarily targeting the same language). > > tl;dr: We want interfaces where plugins can provide tags/symbols to Geany, > so that Geany can use those to build the sidebar/autocompletion/etc. as it > sees fit. Giving the option to override the sidebar will just result in > every plugin doing it differently (and some of them incorrectly), and as a > result yield a poor user interface. > > Full story: > What we really want is methods that allow plugins to provide the *data* that > Geany uses for sidebar/autocomplete/whatever. That means, plugins should be > able to add to the tags storage (tagmanager or otherwise). Then Geany can > use these tags, merge multiple tag sources (=plugins) together and show a > consistent user interface. > > This is somewhat similar to the proxy plugin. By adding an interface to make > Geany learn about the proxied plugins, we avoid stuff like "allow a plugin > to override the PM dialog" which would just result in plugins breaking the > conistnetn user interface. Instead, we achieved a mechanism where Geany can > show plugins that it can't load itself in the same UI as traditional > plugins, making this thing just work seemlessly. > > This should be the design goal when it comes to plugin wanting their own tag > management. Geany must be in the loop so that it can multiplex between > competing plugins and its own functionality, and still present the whole > thing in a consistent manner to the user. > > > Best regards. > ___ > Devel mailing list > Devel@lists.geany.org > https://lists.geany.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] [FT-plugins] Allowing plugins to supply filetype specific functionality
Uhm, where did this thread start? Who are you replying to? Am 26.08.2016 um 09:13 schrieb Lex Trotman: 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. I'm not even sure what the thread is about. Is it replacing ctags through plugins or filetype specific plugins? The latter is much more than just tags. For the former, I can only say that we must avoid trying to take shortcut by adding APIs like "allow a plugin to add its own tags to the sidebar" or "add words to the autocompletion dialog". This is use-case specific, and is going to be troublesome if multiple, competing plugins are at play (not necessarily targeting the same language). tl;dr: We want interfaces where plugins can provide tags/symbols to Geany, so that Geany can use those to build the sidebar/autocompletion/etc. as it sees fit. Giving the option to override the sidebar will just result in every plugin doing it differently (and some of them incorrectly), and as a result yield a poor user interface. Full story: What we really want is methods that allow plugins to provide the *data* that Geany uses for sidebar/autocomplete/whatever. That means, plugins should be able to add to the tags storage (tagmanager or otherwise). Then Geany can use these tags, merge multiple tag sources (=plugins) together and show a consistent user interface. This is somewhat similar to the proxy plugin. By adding an interface to make Geany learn about the proxied plugins, we avoid stuff like "allow a plugin to override the PM dialog" which would just result in plugins breaking the conistnetn user interface. Instead, we achieved a mechanism where Geany can show plugins that it can't load itself in the same UI as traditional plugins, making this thing just work seemlessly. This should be the design goal when it comes to plugin wanting their own tag management. Geany must be in the loop so that it can multiplex between competing plugins and its own functionality, and still present the whole thing in a consistent manner to the user. Best regards. ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
[Geany-Devel] [FT-plugins] Allowing plugins to supply filetype specific functionality
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
