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
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.
Thomas,
#1195, maybe read that and try again.
Cheers Lex
On 27 August 2016 at 06:34, Thomas Martitz kugel@rockbox.org 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
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
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 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.
Small potatoes. If the partial word is not given, many plugins will have to get it each themselves. It's not a big deal to do but maybe at least a helper function or something would be useful to avoid redundant code.
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.
That's good then, I haven't looked at that API much yet.
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.
At least for the CDK (libclang) plugin I was working on, there's no requirement to actually run any external commands, you just call a libclang API function to re-compile and then use its API to extract diagnostics information programmatically. It would be a similar case for Python also. That being said, it's probably beneficial to still allow more generic compiler output parsing in case such nice support libraries are not available.
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.
I remember that. Most likely something along those lines will be a good way to load the plugins, though it might require to be a bit more advanced to deal with plugin lifetimes and other stuff.
Cheers, Matthew Brush
[...]
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ří and Thomas) that using TM as a conveyance mechanism for this may make some sense.
Possibly, so long as its flexible enough to be able to support the particular language symbol and scope structures, then allowing existing code to keep accessing the symbols in the same manner has advantages. But, ATM it doesn't support lexical scope IIUC, the TM experts should comment.
One very important use-case for this is in type inferred languages which are becoming more common (Julia, rust, go, ocaml, haskell, even C++ auto), no ctags parser is going to get types for declarations in those (and may not even recognise `a=b` as a declaration of a) so some external method is gonna be needed.
[...]
Small potatoes. If the partial word is not given, many plugins will have to get it each themselves. It's not a big deal to do but maybe at least a helper function or something would be useful to avoid redundant code.
Yeah, just so long as it doesn't assume C name rules :)
[...]
At least for the CDK (libclang) plugin I was working on, there's no requirement to actually run any external commands, you just call a libclang API function to re-compile and then use its API to extract diagnostics information programmatically. It would be a similar case for Python also. That being said, it's probably beneficial to still allow more generic compiler output parsing in case such nice support libraries are not available.
Yes, thats the idea.
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.
I remember that. Most likely something along those lines will be a good way to load the plugins, though it might require to be a bit more advanced to deal with plugin lifetimes and other stuff.
Yes, and might be even simpler if it can take advantage of any of the new plugin capabilities. IIRC filetypes are never unloaded after loading, so the plugins would have to be the same. Possibly they shouldn't even show in the PM, or show as not user removable.
Cheers Lex
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:
- the time and effort required to make a comment "typo" and the OP
making the change as they do other stuff vs
- the commenter making another PR and the OP having to then combine those.
That's an example of the kind of comments I was hoping to avoid. Either the person can wait until the changes are committed and then add a commit that fixes such trivial errors, send a general cleanup patch to pull requester, or they can wait until the changes are being merged into the master branch to raise such minor issues (eg. during some kind of code review). The goal is that if someone makes some large and/or complicated improvement towards the end goal on a non-master branch, not to bog them down with silly stuff anyone can fix or mention later when it actually matters.
To give an example, it's not uncommon for Columban to do a review and then provide a link to his working branch implementing the changes mentioned, the way he thinks are best. This is a goal, IMO.
[...]
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ří and Thomas) that using TM as a conveyance mechanism for this may make some sense.
Possibly, so long as its flexible enough to be able to support the particular language symbol and scope structures, then allowing existing code to keep accessing the symbols in the same manner has advantages. But, ATM it doesn't support lexical scope IIUC, the TM experts should comment.
One very important use-case for this is in type inferred languages which are becoming more common (Julia, rust, go, ocaml, haskell, even C++ auto), no ctags parser is going to get types for declarations in those (and may not even recognise `a=b` as a declaration of a) so some external method is gonna be needed.
I also have doubts whether TagManager/CTags is up to the task, but I'd like to be proven wrong (would save a lot of work/breakage).
[...]
Small potatoes. If the partial word is not given, many plugins will have to get it each themselves. It's not a big deal to do but maybe at least a helper function or something would be useful to avoid redundant code.
Yeah, just so long as it doesn't assume C name rules :)
[...]
At least for the CDK (libclang) plugin I was working on, there's no requirement to actually run any external commands, you just call a libclang API function to re-compile and then use its API to extract diagnostics information programmatically. It would be a similar case for Python also. That being said, it's probably beneficial to still allow more generic compiler output parsing in case such nice support libraries are not available.
Yes, thats the idea.
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.
I remember that. Most likely something along those lines will be a good way to load the plugins, though it might require to be a bit more advanced to deal with plugin lifetimes and other stuff.
Yes, and might be even simpler if it can take advantage of any of the new plugin capabilities. IIRC filetypes are never unloaded after loading, so the plugins would have to be the same. Possibly they shouldn't even show in the PM, or show as not user removable.
Probably, yeah.
Cheers, Matthew Brush
[...]
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.
That approach is very likely to produce a commit/merge bomb, a big complex change that only those intimately involved with have looked at, discussed, reviewed or tested.
The point of doing development in a branch of the main repo, instead of somebodys own fork, is to make it visible to anyone with a git clone, all they need is `git checkout the_branch; make install` to try stuff out and all the PRs are visible in Geany github to comment on.
The idea is to avoid merge bombs by allowing everyone to have their say during development, not at the end when they have a precipitous learning curve about the new feature, and code, and how it might impact (for good or bad) their workflows, and those who developed it have a large investment which, being human, they naturally feel the need to defend.
This is the pain that has made it hard to make big changes in Geany already, the intent should be to encourage participation no matter how minor, not avoid it. Then the merge becomes a non-event because everybody has already said their piece, and the typos are fixed.
[...]
Probably opening specific Issues and linking back to #1195 would suffice.
Yep
[...]
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.
Well, it needs to be before the paint is bought, and if people are discouraged to comment on the bikeshed they are less likely to be willing to comment on the smoking nuclear reactor in the background.
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:
- the time and effort required to make a comment "typo" and the OP
making the change as they do other stuff vs
- the commenter making another PR and the OP having to then combine
those.
That's an example of the kind of comments I was hoping to avoid. Either the person can wait until the changes are committed and then add a commit that fixes such trivial errors, send a general cleanup patch to pull requester, or they can wait until the changes are being merged into the master branch to raise such minor issues (eg. during some kind of code review). The goal is that if someone makes some large and/or complicated improvement towards the end goal on a non-master branch, not to bog them down with silly stuff anyone can fix or mention later when it actually matters.
It matters when its noticed. Telling people to bugger off and come back later when we are more interested is not the way to run open source developments. Just say "thank you" make the typo fix and be glad that people are at least interested enough to read the code, even if its only superficially its another set of eyes, and nothing is forcing them to contribute.
You say people making small comments is a disincentive to you, so what is it for the person who has taken the time and effort to actually read your code, noticed something and make a suggestion, only to be told "we are not interested in knowing about OUR error until YOU provide a fix/alternative"? Instant turn off.
To give an example, it's not uncommon for Columban to do a review and then provide a link to his working branch implementing the changes mentioned, the way he thinks are best. This is a goal, IMO.
Thats fine if you have a big contribution to make, but its a disincentive for small contributions.
[...]
You can submit PRs to people's PRs, it's easy.
I didn't know you could do that, how?
You forgot to explain how to do this.
Cheers Lex
On 2016-08-27 12:38 AM, Lex Trotman wrote:
[...]
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.
That approach is very likely to produce a commit/merge bomb, a big complex change that only those intimately involved with have looked at, discussed, reviewed or tested.
[...]
Without responding to each thing, the idea behind adding those guidelines was to avoid the problems we have currently whenever trying to make any large changes. The current way is broken and isn't conducive to more than one person actively working on the code and others just pointing out mistakes from their armchair. I wanted to encourage active (ie. code-based) participation rather than one person doing all of the coding in a silo.
Using a separate branch means that every single little thing merged doesn't have to be perfect, stable, ready to release. It would be a work in progress branch that everyone interested is working on code for. It would avoid the current massive PR bomb where everything needs to be 100% complete. This is why I said those minor comments wouldn't be wanted early on. Rather than nitpicking minor details, one could just push a commit fixing them (if non-controversial) or make a PR showing alternatives. That's what I meant by letting the code do the talking.
[...]
You can submit PRs to people's PRs, it's easy.
I didn't know you could do that, how?
You forgot to explain how to do this.
It's just making a PR the usual way, except when doing the web-based part, you choose a different fork rather than Geany's main repo. The web UI isn't super intuitive, but it's not hard at all. If you want to test it out, feel free to make some testing PRs against one of my repos. I'll just close them afterwards, no biggie.
Cheers, Matthew Brush
Le 27/08/2016 à 06:17, Lex Trotman a écrit :
[...]
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.
Possibly, so long as its flexible enough to be able to support the particular language symbol and scope structures, then allowing existing code to keep accessing the symbols in the same manner has advantages.
From what I gathered, using TM for he symbol pane would be just fine for
everybody. It's just providing a set of data describing the items, and if the tags are only used for that they only require some minimal set of data:
* name * scope * kind (function, variable, etc.) * optionally argument list and return type. * optionally anything else we don't yet use.
For auto-completion, it might not be that simple at all. Because being generic code, it might not be able to handle every language's specific syntax where it should show scope completion, calltips, etc. For calltips, imagine a language that don't use parentheses (or anything at all) for specifying argument lists: how will we know we need to show it? Even "just" shell scripts fall into this. So there might at least be an need to trigger some of those things in Geany form a plugin, but probably more generically provide means to override Geany when it can't be taught to behave right.
Maybe it could be as simple as plugins providing tags and telling Geany to complete/scope complete/show calltips at some point, but it might be slightly too optimistic, because no matter what the generic code will always have worse knowledge than the specific one.
But, ATM it doesn't support lexical scope IIUC, the TM experts should comment.
This is IMO a kind of non-issue you keep on bringing :) I mean, yes, there's no such concept yet, but I can't seem to find any reason why it couldn't be like any other tag. A tag that is ignored for anything but resolving the scope, which from the top of my head just means to ignore it when searching for names.
Yes, it would require altering the existing code, but it hardly seem a blocker to me.
I remember that. Most likely something along those lines will be a good way to load the plugins, though it might require to be a bit more advanced to deal with plugin lifetimes and other stuff.
Yes, and might be even simpler if it can take advantage of any of the new plugin capabilities. IIRC filetypes are never unloaded after loading, so the plugins would have to be the same. Possibly they shouldn't even show in the PM, or show as not user removable.
IMO this is kind of unrelated to the issue at hand. Yeah it *might* be nice to auto-load/auto-unload filetype plugins when staring using the filetype, but it's much more of a toy than an actual important design piece if it loads normal plugins (which it probably should, unless proven otherwise). My point is that it adds extra complexity to an already complex-enough issue, seem kinda orthogonal, and only removes the need to manually check a plugin in the PM dialog.
And it's even a complex issue, because you still need to let the users chose not to load those plugins if they don't want them, etc.
Regards, Colomban
On 27 August 2016 at 20:13, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 27/08/2016 à 06:17, Lex Trotman a écrit :
[...]
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.
Possibly, so long as its flexible enough to be able to support the particular language symbol and scope structures, then allowing existing code to keep accessing the symbols in the same manner has advantages.
From what I gathered, using TM for he symbol pane would be just fine for everybody. It's just providing a set of data describing the items, and if the tags are only used for that they only require some minimal set of data:
- name
- scope
- kind (function, variable, etc.)
- optionally argument list and return type.
- optionally anything else we don't yet use.
Yes, the pane is probably the simplest use of the data.
For auto-completion, it might not be that simple at all. Because being generic code, it might not be able to handle every language's specific syntax where it should show scope completion, calltips, etc. For calltips, imagine a language that don't use parentheses (or anything at all) for specifying argument lists: how will we know we need to show it? Even "just" shell scripts fall into this. So there might at least be an need to trigger some of those things in Geany form a plugin, but probably more generically provide means to override Geany when it can't be taught to behave right.
Yes, that would be the best, for the "languages that are C" let Geany do it, and let the plugins do it for the rest.
Maybe it could be as simple as plugins providing tags and telling Geany to complete/scope complete/show calltips at some point, but it might be slightly too optimistic, because no matter what the generic code will always have worse knowledge than the specific one.
Yes, languages will always be finding different ways of doing stuff that is different, so long as the filetype specific plugin can do away with the built-in then it can all be supported.
But, ATM it doesn't support lexical scope IIUC, the TM experts should comment.
This is IMO a kind of non-issue you keep on bringing :)
Well, until this point nobody has actually put a concrete proposal for how to handle it :)
I mean, yes, there's no such concept yet, but I can't seem to find any reason why it couldn't be like any other tag. A tag that is ignored for anything but resolving the scope, which from the top of my head just means to ignore it when searching for names.
Neat, a pseudo-tag representing the lexical scope, and it can have pseudo-tags for enclosing scopes as parents and they can have named scopes for the enclosing function. That sounds like a plan. And if some language has something excruciatingly smart there can be different types of pseudo-tags.
Yes, it would require altering the existing code, but it hardly seem a blocker to me.
Only until an actual solution was proposed :-D
I remember that. Most likely something along those lines will be a good way to load the plugins, though it might require to be a bit more advanced to deal with plugin lifetimes and other stuff.
Yes, and might be even simpler if it can take advantage of any of the new plugin capabilities. IIRC filetypes are never unloaded after loading, so the plugins would have to be the same. Possibly they shouldn't even show in the PM, or show as not user removable.
IMO this is kind of unrelated to the issue at hand. Yeah it *might* be nice to auto-load/auto-unload filetype plugins when staring using the filetype, but it's much more of a toy than an actual important design piece if it loads normal plugins (which it probably should, unless proven otherwise). My point is that it adds extra complexity to an already complex-enough issue, seem kinda orthogonal, and only removes the need to manually check a plugin in the PM dialog.
Well, my point of raising it was to point out it wasn't an issue to be able to activate filetype plugins automatically, my first post said "but it actually was so simple that it doesn't matter."
And it's even a complex issue, because you still need to let the users chose not to load those plugins if they don't want them, etc.
Just set the keys to an empty value in your user filetype file, like anything else there is controlled.
Cheers Lex
Regards, Colomban _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 2016-08-27 03:13 AM, Colomban Wendling wrote:
Le 27/08/2016 à 06:17, Lex Trotman a écrit :
[...]
Yes, and might be even simpler if it can take advantage of any of the new plugin capabilities. IIRC filetypes are never unloaded after loading, so the plugins would have to be the same. Possibly they shouldn't even show in the PM, or show as not user removable.
IMO this is kind of unrelated to the issue at hand. Yeah it *might* be nice to auto-load/auto-unload filetype plugins when staring using the filetype, but it's much more of a toy than an actual important design piece if it loads normal plugins (which it probably should, unless proven otherwise). My point is that it adds extra complexity to an already complex-enough issue, seem kinda orthogonal, and only removes the need to manually check a plugin in the PM dialog.
It's true that at least initially we could just ignore the loading part and do it manually for testing purposes. We could still figure out how a plugin would tell Geany what it provides for what filetypes without loading it automatically from a filetype, but eventually we need some mechanism for this.
And it's even a complex issue, because you still need to let the users chose not to load those plugins if they don't want them, etc.
If we went the filetype-based loader route, the user would choose in the filetype configuration files (or possibly by some future GUI) which plugins to provide support for which filetypes features.
Cheers, Matthew Brush
Le 27/08/2016 à 02:32, Matthew Brush a écrit :
[…]
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.
Just a thought: it would have to be able to respect the user's color scheme. So either read it, or tell Geany which styles it has to set.
Providing a new lexer and a new set of styles sounds better to me just now, but I didn't think too much on it.
Regards, Colomban
Hi Matthew,
some random thoughts.
I'm not sure I agree with doing lots of changes on a separate branch basically without any review. While you will be able to commit things fast to the branch, the most probable outcome will be the branch will get never merged because either nobody will be able to review the changes during merge or there will be some disagreement about something that could have been caught early. And then it's just lost effort.
The individual points here
https://github.com/geany/geany/issues/1195
look like they should be able to do one by one. The most useful seems to be the code completion so this might be the one to start with. In parallel it would be good to develop a plugin that uses the new API and get it to a really usable state - you won't be able to tell what exactly you need for the plugin unless you have some working code. In parallel you can get some feedback from users and they will have something useful rather than lots of half-finished prototype features that aren't really usable.
My other question is who wants to work on this? The issue mentions only those providing patches should be involved but is there anyone except you who will contribute patches? I confess this isn't very interesting for me - I'm not so terribly tied to Geany and if I wanted e.g. a dedicated C++ editor, I'd grab something else - you always get better language support if the editor is made specifically for your needs. I use Geany as a general purpose editor but otherwise use also Android Studio and XCode when writing for Android or iOS. So no patches from me I'm afraid :-(. Apart from that this is a huge amount of work and I'm just lazy, sorry ;-)
Cheers,
Jiri
On 2016-08-28 08:47 AM, Jiří Techet wrote:
Hi Matthew,
some random thoughts.
I'm not sure I agree with doing lots of changes on a separate branch basically without any review. While you will be able to commit things fast to the branch, the most probable outcome will be the branch will get never merged because either nobody will be able to review the changes during merge or there will be some disagreement about something that could have been caught early. And then it's just lost effort.
A branch can be merged into master more than once (or we could use multiple-branches). No reason it has to happen in a single merge, or without any review.
The individual points here
https://github.com/geany/geany/issues/1195
look like they should be able to do one by one. The most useful seems to be the code completion so this might be the one to start with. In parallel it
That or highlighting, not sure.
would be good to develop a plugin that uses the new API and get it to a really usable state - you won't be able to tell what exactly you need for the plugin unless you have some working code. In parallel you can get some feedback from users and they will have something useful rather than lots of half-finished prototype features that aren't really usable.
I have previously started writing the CDK plugin[0] but gave up for the time being since most of what I wanted to implement either a) wasn't possible b) wasn't possible without ugly hacks or c) wasn't possible without the user manually disabling stuff in the prefs dialog and completely replacing the feature from the ground up.
I would probably like to use this as a proof of concept, although only having one plugin for one family of statically typed languages using one support library might not give the fullest view of what's needed.
My other question is who wants to work on this? The issue mentions only those providing patches should be involved but is there anyone except you who will contribute patches? I confess this isn't very interesting for me -
We'll see. I know Columban has expressed interest (or at least stated that it's probably the best approach) in the past, not that that means he's interested in actively contributing to the effort. Anyone is welcome to contribute.
I'm not so terribly tied to Geany and if I wanted e.g. a dedicated C++ editor, I'd grab something else - you always get better language support if the editor is made specifically for your needs. I use Geany as a general
This isn't necessarily true, there's lots of language-agnostic editors/IDEs that people use that allow customized language support (vim, eclipse, emacs, etc). The problem with Geany is it doesn't allow any filetype customization besides what you can set in the filetypes.* files, it doesn't allow extension of any of the built-in features.
purpose editor but otherwise use also Android Studio and XCode when writing
I sometimes use QtCreator when I need proper C/C++ support but it's annoying having to use an editor I don't like when I know that Geany can (and does now, just not well) do the same things with the assistance of language-specific support libraries.
for Android or iOS. So no patches from me I'm afraid :-(. Apart from that this is a huge amount of work and I'm just lazy, sorry ;-)
That's fine. I don't expect it to be a _huge_ amount of work, but probably not a simple one-off PR. I expect it to be similar in scope and size to the proxy plugin improvements, most likely.
Cheers, Matthew Brush
That's fine. I don't expect it to be a _huge_ amount of work, but probably not a simple one-off PR. I expect it to be similar in scope and size to the proxy plugin improvements, most likely.
Forgot to say I can of course help you if you aren't sure about something in TM - I'm quite familiar with it now.
Jiri