> Speaking of it, what about four space tab-stops for new and updated code
>> (of course not for the sake of it)?
>>
> In the eternal conflict between tabs vs spaces i'm a tabs supporter too.
> However in scid we try to maintain file consistency: when patching a file
> that used spaces you should u
Cristian Stoica wrote:
> Sure, we could simply commit the code and let users find if it add any
> bugs, but i think it's not the right way.
> I'm against taking patches without review and testing. I fall into
> this trap myself times and times again. I needed to know if the
> example was to make
>...but the current code is in use by more than 4 years and there are no
bug reports.
No bug reports doesn't mean there are no bugs. For example, I have three of
them in my queue (two for fics) that I did not report.
Sure, we could simply commit the code and let users find if it add any
> bugs, bu
Cristian Stoica wrote:
> You could argue the reverse if the patch was already there and then
> removed
Exactly, but the current code is in use by more than 4 years and there
are no bug reports.
I'm not saying that adding "split" is wrong; the point is that it makes
the code more robust, but it
You could argue the reverse if the patch was already there and then removed
for not adding visible value.
But not unless there was a real case where the removal would regress (e.g.
because the parsed text is not regular).
Does the addition regress?
The fact that 'split' adds an empty element in y
