On Mon, Dec 26, 2011 at 5:56 PM, Cedric BAIL <cedric.b...@free.fr> wrote:
> On Mon, Dec 26, 2011 at 8:53 PM, Christopher Michael
> <cpmicha...@comcast.net> wrote:
>> On 12/26/11 05:22, Michael Blumenkrantz wrote:
>>> On Mon, 26 Dec 2011 03:27:17 -0500
>>> Christopher Michael<cpmicha...@comcast.net> 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
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
