There were a couple of discussions before on this topic. I gave up removing trailing white spaces because they're out of concern for the most e-devs. And even committers are continuously pushing them in.
Daniel Juyung Seo (SeoZ) On Wed, Dec 28, 2011 at 3:10 AM, Rafael Antognolli <[email protected]> wrote: > On Mon, Dec 26, 2011 at 5:56 PM, Cedric BAIL <[email protected]> wrote: >> 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... > > And an easier solution is to simply highlight them... > > -- > Rafael Antognolli > ProFUSION embedded systems > http://profusion.mobi > > ------------------------------------------------------------------------------ > 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 ------------------------------------------------------------------------------ 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
