On Mon, Dec 08, 2003 at 12:03:00AM -0500, Dimitrie O. Paun wrote:
Only whitespace changes. Unfortunately, the formatting was all messed up by having tabs of 4 and 8 chars (I said it before, and I'll say it again: the only sane way of dealing with tabs is to always use the standard size of 8 chars. Anything else is too complicated to ever work reliably).
Just to flame a bit (the lists were a bit quiet lately) : the only sane way to dealing with TABs is when TABs are used properly (ie by an editor that uses them only to go to the current C indenting level and uses spaces for everything that comes after).
With such an editor, tab size does not matter at all.
No idea if Emacs / Vi can be used to work like that :-)
Lionel
On December 8, 2003 01:09 pm, Lionel Ulmer wrote:
Just to flame a bit (the lists were a bit quiet lately) : the only sane way to dealing with TABs is when TABs are used properly (ie by an editor that uses them only to go to the current C indenting level and uses spaces for everything that comes after).
(true, they are sort of quiet... time to make some noise! :) )
Well, I beg to differ -- I think *my* method is the only sane way! :)))
Seriously, I have heard the argument with the smart editor before, but I'm afraid it never works out because people sometimes indent using spaces. It simply requires a level of discipline that it's simply too much to expect anyone to follow. Yes, you could argue that the editor should go and automagically replace spaces with tabs where appropriate, but this is still not feasible because a lot of people touch the code, and even the same person touches it using different editors, from different boxes, etc. How are you going to make sure everyone has their editors setup just so (if at all possible!)? Face it, there's no way it can work, especially in an internet-like setting where you simply can not impose such strict environmental constraints on people.
This clearly falls in the "doctor, it hurts when I do that" category. Tab has a standard size, and that is 8. As long as we don't go about changing that for no good reason whatsoever, we wouldn't have any problems.
but this is still not feasible because a lot of people touch the code, and even the same person touches it using different editors, from different boxes, etc. How are you going to make sure everyone has their editors setup just so (if at all possible!)? Face it, there's no way it can work, especially in an internet-like setting where you simply can not impose such strict environmental constraints on people.
Of course we can : we have a nice quality gate called 'Alexandre' which commits all the patches. So we just need to, either :
1) write a tool that checks the source code for correct tabbing and rejects the patch if it does not follow THE RULES
2) or even better, write a re-tabulator which produce source code following THE RULES (tool that would be applied to all source code on each commit).
So it's certainly possible to have it working :-)
Lionel
On December 8, 2003 02:52 pm, Lionel Ulmer wrote:
- write a tool that checks the source code for correct tabbing and
rejects the patch if it does not follow THE RULES
Again, not feasible -- I for one edit wine stuff from multiple boxes, multiple editors, I don't want to have to learn how to setup editors on every box I move to.
- or even better, write a re-tabulator which produce source code
following THE RULES (tool that would be applied to all source code on each commit).
This is a real bad idea. We had that we trailing whitespace, and it was a nightmare because CVS would detect that as conflicts so it was sooo hard to work with: submit, wait for Alexandre to commit, update, understand/resolve conflitcs. And for large changes, you can only do cvs up -C, which means you can't keep working until Alexandre commits. Too nasty for words.
We can argue till the cows come home, but I think we've lost track of the purpose. Are we trying to make our lives more difficult? If so, we're on the right track :) Is this 'problem' (that we're creating) worth dealing with all this complication? For what purpose?
Lionel Ulmer lionel.ulmer@free.fr writes:
Of course we can : we have a nice quality gate called 'Alexandre' which commits all the patches. So we just need to, either :
write a tool that checks the source code for correct tabbing and rejects the patch if it does not follow THE RULES
or even better, write a re-tabulator which produce source code following THE RULES (tool that would be applied to all source code on each commit).
If I have to enforce a rule, the rule will be: no tabs allowed whatsoever. So be careful what you wish for ;-)
On Mon, Dec 08, 2003 at 12:30:57PM -0800, Alexandre Julliard wrote:
If I have to enforce a rule, the rule will be: no tabs allowed whatsoever. So be careful what you wish for ;-)
Well, this would really be the best solution I think.
At 'real' work we have a no-TAB rule and it's the only real way to work with heterogenous text editors while having consistant displayin. Of course, the 'tab' size is 4 spaces, so some people are bound to complain, but well :-)
Lionel (who really needs to configure his home Emacs one of this days to NOT use <tab> at all in the code source it edits)
Lionel Ulmer wrote:
but this is still not feasible because a lot of people touch the code, and even the same person touches it using different editors, from different boxes, etc. How are you going to make sure everyone has their editors setup just so (if at all possible!)? Face it, there's no way it can work, especially in an internet-like setting where you simply can not impose such strict environmental constraints on people.
Of course we can : we have a nice quality gate called 'Alexandre' which commits all the patches. So we just need to, either :
write a tool that checks the source code for correct tabbing and rejects the patch if it does not follow THE RULES
or even better, write a re-tabulator which produce source code following THE RULES (tool that would be applied to all source code on each commit).
So it's certainly possible to have it working :-)
Lionel
Not to mention that, a while back, I offered to write a small perl script that will bring all sent patches into a consistent format. I never even heard back from anyone what format this patch can expect to receive and send the mail, nor what the system is running.
And that was a non-controversial change (well, Dimi objected, IIRC. Like I said).
Shachar
--- Shachar Shemesh wine-devel@shemesh.biz wrote:
And that was a non-controversial change (well, Dimi objected, IIRC. Like I said).
There was a perl script that Patrik wrote the do the conversion of the whole Winehq source tree. We should really just run this script once a year or something. At some point I will get around to doing this on any of the ReactOS code that we may share with Winehq in the future.
Thanks Steven
__________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/
On December 8, 2003 03:58 pm, Shachar Shemesh wrote:
Lionel Ulmer wrote:
- or even better, write a re-tabulator which produce source code
following THE RULES (tool that would be applied to all source code on each commit).
So it's certainly possible to have it working :-)
LionelNot to mention that, a while back, I offered to write a small perl script that will bring all sent patches into a consistent format. I never even heard back from anyone what format this patch can expect to receive and send the mail, nor what the system is running.
Um, there was a fair bit of discussion as I recall - and Alexandre expressed an interest along the way too. For my part, I may have thrown too many spanners into the works (having the script customisable for individual users to rewrite mails into their preferred layout - eg. Dimi doesn't like attachments). However I'm curious that you thought noone was interested, because I for one have been very much looking forward to seeing how it works out! :-)
Cheers, Geoff
Geoff Thorpe wrote:
On December 8, 2003 03:58 pm, Shachar Shemesh wrote:
Lionel Ulmer wrote:
- or even better, write a re-tabulator which produce source code
following THE RULES (tool that would be applied to all source code on each commit).
So it's certainly possible to have it working :-)
LionelNot to mention that, a while back, I offered to write a small perl script that will bring all sent patches into a consistent format. I never even heard back from anyone what format this patch can expect to receive and send the mail, nor what the system is running.
Um, there was a fair bit of discussion as I recall - and Alexandre expressed an interest along the way too. For my part, I may have thrown too many spanners into the works (having the script customisable for individual users to rewrite mails into their preferred layout - eg. Dimi doesn't like attachments). However I'm curious that you thought noone was interested, because I for one have been very much looking forward to seeing how it works out! :-)
On the contrary. I said that, except for Dimi (who doesn't like attachments), everyone WERE interested. It's just that, in order to write such a script, I need to know whether I can ask for perl modules installed on the server, how is my script going to interact with the mail system, etc. I never got answers to those questions.
Cheers, Geoff
Shachar
On December 9, 2003 12:43 am, Shachar Shemesh wrote:
On the contrary. I said that, except for Dimi (who doesn't like attachments), everyone WERE interested.
I was interested as well, it's just that I prefer inline patches rather than text/plain attachments. But if Alexandre likes attachments better ...
It's just that, in order to write such a script, I need to know whether I can ask for perl modules installed on the server, how is my script going to interact with the mail system, etc. I never got answers to those questions.
Just Do It (TM). Yes, assume perl modules, make some assumtions about the mail interaction, it's not that important at this stage...
-
Alexandre Julliard -
Dimitrie O. Paun -
Geoff Thorpe -
Lionel Ulmer -
Shachar Shemesh -
Steven Edwards