CodeLite IDE

Although I noticed it before, one of the latest issues in question is this. Okay, so the issue might be inherited from Scintilla editor component, but it's still an issue affecting CodeLite, so why does it get closed? My own reasoning would be that issue that is still valid to remain open, at least for reference (maybe as part of "known issues"), even if you don't have plans to fix it any time soon or it's cannot be fixed on product side (although that specific issue in question - I wonder if a temporary workaround could be made on CL part). In this case, replying to the issue and asking OP (in this case, myself) to create a cross-referenced bug report on Scintilla would probably work - I would definitely bother to help redirect this out, but closing it just seems a way to tell me to "f@$k off". This particular issue is quite an usability gimmick and does affect productivity, too bad it's dismissed so easily.

The second case is a feature request mentioned here. Okay, so the answer was a pretty way to say "f@$k it, just do it yourself". Understandable, but still, why closing it? Leaving it open for reference would mean acknowledging that it could be an important contribution, in case someone decides to dig into code to try working on it, myself included, but closing it seems like an easy way to dismiss a potentially great feature.

I'm sorry, but I find it difficult to expect that someone would bother looking into requests and reports that are closed to see if there is something cool down there. Therefore, when you close a report without having it fixed/implemented, it just goes down to the trash. This whole approach slightly bothered me for a while, but maybe I just don't understand CodeLite development philosophy.

lifepower wrote:Okay, so the issue might be inherited from Scintilla editor component, but it's still an issue affecting CodeLite, so why does it get closed

Simply because there is no code to commit to fix this from our side. It will get fixed once the 3rd part component will implement / fix this.

In general, my approach is: keep the issue tracker for issues that we do plan on fixing (by writing "we" I exaggerate here, it's mainly David and I)
If I don't plan on fixing this, I don't keep it open - easier for my to maintain the issue list.

lifepower wrote:"f@$k it, just do it yourself". Understandable, but still, why closing it? Leaving it open for reference would mean acknowledging that it could be an important contribution, in case someone decides to dig into code to try working on it, myself included, but closing it seems like an easy way to dismiss a potentially great feature.

In theory you are correct, but in reality, the the percentage of issues contributed by pull requests to CodeLite is somewhere between slim to none, also its worth mentioning that most of the PR CodeLite received is adding functionality that people think that **they** miss, I rarely receive a PR that fixes an issue from the tracker

See the contributor page to see how many people actually did took the time to submit PRs: https://github.com/eranif/codelite/graphs/contributors
Its an improvement comparing to the sourceforge days /w SVN, but still we have a big room for improvements

Eran