Magnus Lundin wrote:
> Dick Hollenbeck wrote:
>   
>> Laurent Gauch wrote:
>>   
>>     
>>>> Dick Hollenbeck wrote:
>>>>     
>>>>       
>>>>         
>>>>> / Are other folks having problems with tab expansion differences between 
>>>>>       
>>>>>         
>>>>>           
>>>> />/ editors?
>>>> />/ 
>>>> />/ I load jtag.c into two different editors and get two different results 
>>>> />/ when tab width is set to 4.
>>>> />/ 
>>>> />/ This makes it difficult to view a table like tms_seq in the two 
>>>> />/ editors.  The editors are well established, JEdit and gedit.
>>>> />/ 
>>>> />/ This reminds me why in my own source code internally, we don't use 
>>>> tabs.
>>>> />/ 
>>>> />/ It extremely hard to mis-interpret the width of a space, and my hard 
>>>> />/ disk, compiler, and eyes cannot tell the difference.
>>>> />/ 
>>>> />/ What are you seeing when you look at tms_seq?  Does it look nice and 
>>>> />/ organized neatly into columns?
>>>> />/ 
>>>> />/ 
>>>> />/ Dick
>>>> /
>>>> Looks bad in vim with ts=8 and ts=4. You can correct it for one but 
>>>> change to the other and it looks bad again. I tend to agree with you in 
>>>> this case that spaces are better for column alignment. However, not sure 
>>>> that this totally justifies banning tabs.
>>>> -gene
>>>>     
>>>>       
>>>>         
>>> Looks very Bad for me too.
>>>
>>> We should replace all TABs in all openocd files and replace by 2 or 3 
>>> SPACEs.
>>>
>>> TABs only have the advantage to make some files smaller.
>>> SPACEs are spaces and ever spaces ;-)
>>>
>>> PS: I never use TABs, but 2x SPACES instead.
>>>   
>>>     
>>>       
>> See I use 4 spaces for C,C++, and Java. 
>>
>> So this brings us to the reason some folks thought that tabs were once a 
>> good idea.  That you could change the width on tabs and suit the 
>> personal tastes of everyone.  This only works if you restrict the tabs 
>> to the initial whitespace on the line.  And even then it falls down if 
>> there is formatting after that.  Most editors cannot do that anyway.
>>
>> There is no perfect solution, but I agree that spaces are superior on 
>> balance. 
>>
>> It would have to be a policy decision because whitespace gets noticed by 
>> patches and the SVN system.  However, if there was a patch filter 
>> program written, then in theory patches could be passed through a filter 
>> before being submitted.  On check out, you could get the source in the 
>> form you want.  This is a variation on the theme that Harboe pointed 
>> at.  It could be a website where you submit the file and get it back via 
>> http.  This would not change the C formating, only the whitespace 
>> formatting.
>>   
>>     
> I dont fancy the idea of having to run everything through some extra web 
> based filter.
>   
>> Please, let's brainstorm for awhile and give this serious consideration, 
>> and avoid the early injection of "the consensus is" posting that has 
>> tended to thwart serious discussion of potential improvements recently.
>>
>>
>> Tabs are not a good solution, and I don't care if Linus likes them, I don't.
>>   
>>     
> Tabs as indentation is very nice IMHO,  it makes it much easier to move 
> some lines inside / outside indented blocks. One tab per line instead of 
> 4 spaces.
>   

What's wrong with your text editor?  Can't do this with spaces?

>> Python uses spaces.
>>   
>>     
> Python is perfectly happy with tabs, but bad things happens when you mix.
>   

Python's recommended coding style guidelines say to use spaces.  It is 
"pythonic" to use spaces, and taboo to use tabs.

>> Dick
>>
>>
>> _______________________________________________
>> Openocd-development mailing list
>> Openocd-development@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/openocd-development
>>   
>>     
> Tabs for me.
>
> Magnus
>   

Thanks for commenting.   So far you seem to be in the minority, 2 for, 1 
against, 2 unclear.  This is a matter of opinion, so it is sort of like 
arguing about what is the best color.  An argument should not ensue.


Dick

_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to