2 ms·

I love geany for loose file edits, but I don't use as an IDE. For one thing (perhaps this has changed in the 2.0?) no "proper" split window support; there was a

I love geany for loose file edits, but I don't use as an IDE. For one thing (perhaps this has changed in the 2.0?) no "proper" split window support; there was a patch implementing it a few years back, but it was refused on religious reasons (read, "not done the way we want it so we're going to do it ourselves instead and in fact never came around to it"). Still, great editor, super fast, and the fact you can easily open a file in your currently open session (and that it supports the <filename>:<line number> convention) makes it super for checking out error message/warnings etc when compiling code that you don't have in an IDE...

himo3 3y ago
I would not call that religious reasoning. Accepting a patch is accepting responsibility. Each line is a liability, not an asset. Thus, if the maintainers did not think the patch is worth carrying the burden, I can understand. And if the patch would be easy to carry and there was a demand for it, it would be trivial to run a fork, wouldn't it?
- freedomben 3y ago
  I think saying each line is a liability is a bit overly pessimistic. At least, to be consistent you would have to say that every line in the entire code base is a liability. That may be true, but it fails to accurately capture the value of the code in the first place. Nevertheless, I agree with you that I would not call it religious reasoning. When something is implemented in a way that does not follow existing patterns well, or forges a new path, it can make maintenance much more difficult. Given that the original author is rarely available to help with bugs and other maintenance for the new code, it is very reasonable in my opinion to reject changes that Don't conform well to existing patterns, or do things in a way that the future maintainers would not approve of. A suggestion for people contributing to open source projects: try as much as possible to follow the existing patterns in the code base. It can be a pain to try to learn the patterns, particularly when you just want to add something simple, but it greatly increases the odds of acceptance, and added value in the future. If you want your code to be appreciated by the maintainers, it needs to look like code they would have written themselves. The best way to determine what that code would look like, is by emulating the patterns of the existing code.
- thiht 3y ago
  > Each line is a liability, not an asset. I understand the intent, but this is a really bad take, and honestly an awful vision of what programming is. You write lines of code to solve problems, implement a vision, create a product, improve behaviors or fix bugs. If a line of code goes in this direction, it’s definitely an asset. If a line of code goes against this, it’s a liability. With your vision, the best program is no program, which can be true when there’s no problem to solve. But the thing is we actually have problems to solve that require lines of code.
airtonix 3y ago
[dead]

himo3 3y ago

I would not call that religious reasoning. Accepting a patch is accepting responsibility. Each line is a liability, not an asset. Thus, if the maintainers did not think the patch is worth carrying the burden, I can understand. And if the patch would be easy to carry and there was a demand for it, it would be trivial to run a fork, wouldn't it?

freedomben 3y ago
I think saying each line is a liability is a bit overly pessimistic. At least, to be consistent you would have to say that every line in the entire code base is a liability. That may be true, but it fails to accurately capture the value of the code in the first place. Nevertheless, I agree with you that I would not call it religious reasoning. When something is implemented in a way that does not follow existing patterns well, or forges a new path, it can make maintenance much more difficult. Given that the original author is rarely available to help with bugs and other maintenance for the new code, it is very reasonable in my opinion to reject changes that Don't conform well to existing patterns, or do things in a way that the future maintainers would not approve of. A suggestion for people contributing to open source projects: try as much as possible to follow the existing patterns in the code base. It can be a pain to try to learn the patterns, particularly when you just want to add something simple, but it greatly increases the odds of acceptance, and added value in the future. If you want your code to be appreciated by the maintainers, it needs to look like code they would have written themselves. The best way to determine what that code would look like, is by emulating the patterns of the existing code.
thiht 3y ago
> Each line is a liability, not an asset. I understand the intent, but this is a really bad take, and honestly an awful vision of what programming is. You write lines of code to solve problems, implement a vision, create a product, improve behaviors or fix bugs. If a line of code goes in this direction, it’s definitely an asset. If a line of code goes against this, it’s a liability. With your vision, the best program is no program, which can be true when there’s no problem to solve. But the thing is we actually have problems to solve that require lines of code.

airtonix 3y ago

[dead]