Hi guys,
I know everybody is busy with release of geany 1.24 . Can somebody please find sometime to merge PR#226https://github.com/geany/geany/pull/226 so that it goes to geany release 1.24?
If there is some problem please do tell me. I would fix it asap.
Thanks, Shankhoneer Chakrovarty
On Thu, 27 Mar 2014 16:27:07 -0700 Shankhoneer Chakrovarty shankhoneer@gmail.com wrote:
Hi guys,
I know everybody is busy with release of geany 1.24 . Can somebody please find sometime to merge PR#226https://github.com/geany/geany/pull/226 so that it goes to geany release 1.24?
If there is some problem please do tell me. I would fix it asap.
Min fields are fixed, but:
It still supports the buildin parser only (not regex), and the "gcc like" syntax only (though the D and HTML examples have warnings).
It still assumes that "warning" is at line_idx + 2 (unless I'm missing something), though the examples for the so called "gcc type error" for JAVA and LATEX have it at line_idx + 1.
Last and least, pull request #191 and SF patch #11 are earlier than #226. If one of them is applied, #226 will be seriously broken.
But we already discussed all this. Why do you insist on #226 in it's current form?
Thanks Dimitar. Please find my response below.
Hi guys,
I know everybody is busy with release of geany 1.24 . Can somebody please find sometime to merge PR#226https://github.com/geany/geany/pull/226 so that it goes to geany release 1.24?
If there is some problem please do tell me. I would fix it asap.
Min fields are fixed, but:
It still supports the buildin parser only (not regex), and the "gcc like" syntax only (though the D and HTML examples have warnings).
It still assumes that "warning" is at line_idx + 2 (unless I'm missing something), though the examples for the so called "gcc type error" for JAVA and LATEX have it at line_idx + 1.
Yes PR#226 is specific for C/C++ warnings and that too for gcc like compiler error messages for c/cpp which has 'warning' keyword in line_idx+2, for all other languages (other than C/C++) the PR is harmless, it falls back to the behavior geany has now, show red squiggly line irrespective of warning or error. I can do that for other programming languages too, but I am not sure whether people programming in those languages like to see different coloring scheme for warning and error.
I have not changed the regex parser because I am still trying to find how regex parsing of compiler errors works in geany, its taking longer than I expected.
Last and least, pull request #191 and SF patch #11 are earlier than
#226. If one of them is applied, #226 will be seriously broken.
I had no idea about these PRs. Thanks for pointing this out. I will check them.
But we already discussed all this. Why do you insist on #226 in it's
current form?
So I guess what you are trying to suggest is: 1. Generalize the behavior for all the programming languages supported by geany. I have to find out which languages generate warning messages and which dont, this may take some time. 2. Remove the hard coding of line_idx+2 3. Make changes for both regex parsing as well as older parsing method
If I make these changes, will then you merge the PR? Or Do I need to do more changes? Please feel free to give me feedback. I am new to geany development and I am primarily use geany for C++/Python programming so I am very biased towards these languages and might miss the bigger picture.
Thanks, Shankhoneer Chakrovarty
On Fri, 28 Mar 2014 12:06:24 -0700 Shankhoneer Chakrovarty shankhoneer@gmail.com wrote:
Last and least, pull request #191 and SF patch #11 are earlier than
#226. If one of them is applied, #226 will be seriously broken.
I had no idea about these PRs. Thanks for pointing this out. I will check them.
Hmmm... I wrote to the mailing list about them, answering to "shan chak shankholove@gmail.com", though that's not identical to your account.
So I guess what you are trying to suggest is:
- Generalize the behavior for all the programming languages supported by
geany. I have to find out which languages generate warning messages and which dont, this may take some time.
For the old parser, I think covering the example messages will be enough.
- Remove the hard coding of line_idx+2
Looking at the D/HTML examples, a simple indexing will not work.
- Make changes for both regex parsing as well as older parsing method
Regex should be covered, of course... though that'll lead to even more conflicts between PR #226 and PR #191-or-SF patch #11.
If I make these changes, will then you merge the PR? Or Do I need to do more changes? Please feel free to give me feedback. [...]
Disclaimer: I'm not a leading developer, and can't merge your changes. What I can tell you, however, is that the current partial PR #226 is not very likely to be considered.
As the author of SF patch #11, I plan to extend it for warnings, using code from PR #226, except for the parsing. But I don't have time now.
Thanks Dimitar :)
Last and least, pull request #191 and SF patch #11 are earlier than
#226. If one of them is applied, #226 will be seriously broken.
I had no idea about these PRs. Thanks for pointing this out. I will check them.
Hmmm... I wrote to the mailing list about them, answering to "shan chak shankholove@gmail.com", though that's not identical to your account.
Thats me but different account.
As the author of SF patch #11, I plan to extend it for warnings, using code from PR #226, except for the parsing. But I don't have time now.
Well thats fine by me. If I can be of any help to you to speed up the process please do tell me. I would be happy to help :)
Thanks, Shankhoneer Chakrovarty