On Mon, Dec 26, 2011 at 8:53 PM, Christopher Michael <[email protected]> wrote: > 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.
Mine do remove the trailing whitespace in that case... -- Cedric BAIL ------------------------------------------------------------------------------ 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
