On 12/26/11 05:22, Michael Blumenkrantz wrote:
> On Mon, 26 Dec 2011 03:27:17 -0500
> Christopher Michael<[email protected]> wrote:
>
>> On 12/26/11 00:17, Michael Blumenkrantz wrote:
>>> can we have a rule that there will be ZERO whitespace-related commits from
>>> now on?
>>
>> Good luck with that :P It's just something that DOES happen...if on
>> purpose (or not), it still Does happen. Have to deal w/ it. After 10-15
>> years of trying to keep EFL formatting, I've given up ;)
>>
>> it clutters up the log and serves no purpose. if we want to be really
>>> particular about it,
>> Well, if that WAS the case then We'd still be in the stone ages wrt
>> efl/e cause MANY (if not all) patches that come across are Never
>> formated as per E/EFL rules. People just don't follow what's been
>> established :( (they'd rather code to their own rules, and that's a
>> pretty much "given" truth)
>>
>> we should just have a single commit to do this just before
>>> a release.
>>>
>> Well, THAT, or just ignore whitespace in patches. IE: If a patch
>> includes a good fix, then go for it. If same patch ALso includes
>> formatting fixes, then accept it and fix the "whitespace" issues later.
>> If said patch fixes a real bug, accept it. The formatting can be fixed
>> later.
>>
>> Whitespace (in and of itself) is not that big a deal (unless the
>> formatting is terribly wrong in which case, we tell the patcher to @
>> least "try" to adhere.) and can be easily ignored (if patch reviewer
>> just looks @ the code itself). The only thing unacceptable (imo) is all
>> this "wasted" whitespace wrt trying to align variables. We all know what
>> I am talking about:
>>
>> Evas_Object *myobj;
>> Evas *myevas;
>>
>> Is Easier to read (cause human brain normally goes left to right), Than:
>>
>> Evas_Object *myobh
>> Evas *myevas
>>
>> Now, I have to read "hey, there's an Evas" ... let me page over and see
>> what the variable name is ... UUGGG What a waste (of time AND whitespace)...
>>
>> Having said that:
>>
>> If the "fix" is good, then the "formatting" can be fixed later...just my
>> 2 cents....
>>
>> dh
>>
> well, I was mainly talking about trailing whitespaces (which are not
> formatting-related). I suppose I should have specified. I do agree with your
> points, however.
>
Ahhh, Trailing whitespaces...I see. Yea, those can be annoying, but
sometimes they are not "avoidable". I know that code I write sometimes
has them, but it's normally the 'editor' which is doing it. Ie, if I
write a line:
if (variable) {
then while writing it, when I get to the bracket my editor automatically
puts the bracket on the next line (with the proper indented space for
efl formatting) and what gets left is what looks like a 'trailing'
whitespace.
dh
------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
