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