Re: Tabs are EVIL *and* STUPID, end of discussion. (Re: Tabs versus Spaces in Source Code)
achates wrote: Andy Sy wrote: Don't be evil - always configure your editor to convert tabs to true spaces. Yet another space-indenter demonstrates that problem actually lies with people who think that tab == some spaces. Wrong. I am completely aware that an editor configured to convert tabs to true spaces will not always replace a tab into the same number of space characters. If you understood what I meant you'd realize that it meant: Use the tab key if you have to (4,8,3,2... whatever...), but /always/ have your editor convert them to true spaces, so they can display properly - *without need for tweaks* - on any display medium and on anyone's program. The fact that a tab character doesn't necessarily equal a constant spaces is what makes things EVEN MORE CONFUSING. Cheez... some people just love complexity for its own sake... What earthly benefit is there anyway to mixing tabs and spaces??!? Now... if you say you SHOULDN'T mix tabs and spaces (indeed this is generally regarded as a BAD idea esp. in Python code), then WHAT THE HECK do you need to use tab characters in the source code for anyway (besides saving a measly few bytes) ??!? Tab characters are EVIL *AND* STUPID. Sorry to hear that. You should try using an editor that's easier for you. I am *most certainly* NOT giving SciTE up... I've spent years and years looking for the perfect editor, and I've found it with SciTE. Scite and all its cool features are NOT the problem. One single thing is: Tab characters in source code popping up like so many unsightly zits. -- It's called DOM+XHR and it's *NOT* a detergent! -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs are EVIL *and* STUPID, end of discussion. (Re: Tabs versus Spaces in Source Code)
Andy Sy enlightened us with: Now... if you say you SHOULDN'T mix tabs and spaces (indeed this is generally regarded as a BAD idea esp. in Python code) I indeed say so. then WHAT THE HECK do you need to use tab characters in the source code for anyway (besides saving a measly few bytes) ??!? To separate layout (how much indentation is used) from semantics (how many intentation levels). Tab characters are EVIL *AND* STUPID. And someone who needs to resort to all-caps words (which many consider shouting) needs to relax and use proper arguments. Sybren -- The problem with the world is stupidity. Not saying there should be a capital punishment for stupidity, but why don't we just take the safety labels off of everything and let the problem solve itself? Frank Zappa -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs are EVIL *and* STUPID, end of discussion. (Re: Tabs versus Spaces in Source Code)
Sybren Stuvel wrote: then WHAT THE HECK do you need to use tab characters in the source code for anyway (besides saving a measly few bytes) ??!? To separate layout (how much indentation is used) from semantics (how many intentation levels). Like I said, you'll *NEVER* get that fancy shmancy 'semantic indentation' idea to work properly in the most basic utilities which have the 8-space tabs assumption hardcoded in them. Code with anything other than 8-space tabs will *NEVER* display properly using everyday unix utilities such as less and cat. But then, 8-space tabs are just too wide to be practical, thus the simple conclusion I have reached: JUST STOP USING THEM. Heck, all those who actually believe that make's requirement of an invisible tab as a 'semantic' marker was a good idea raise their hands...! rolling-eyes-to-high-heaven Tab characters are EVIL *AND* STUPID. And someone who needs to resort to all-caps words (which many consider shouting) needs to relax and use proper arguments. I know when I'll be able to relax... when I no longer need to waste time dealing with those stupid tabs in source code!!! ;-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs are EVIL *and* STUPID, end of discussion. (Re: Tabs versus Spaces in Source Code)
Andy Sy enlightened us with: Like I said, you'll *NEVER* get that fancy shmancy 'semantic indentation' idea to work properly in the most basic utilities which have the 8-space tabs assumption hardcoded in them. Fair enough. How much code is viewed with less and cat, and how much is viewed using smart viewers/editors? I think the majority is viewed using the latter. Sybren -- The problem with the world is stupidity. Not saying there should be a capital punishment for stupidity, but why don't we just take the safety labels off of everything and let the problem solve itself? Frank Zappa -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs are EVIL *and* STUPID, end of discussion. (Re: Tabs versus Spaces in Source Code)
Sybren Stuvel wrote: Andy Sy enlightened us with: Like I said, you'll *NEVER* get that fancy shmancy 'semantic indentation' idea to work properly in the most basic utilities which have the 8-space tabs assumption hardcoded in them. Fair enough. How much code is viewed with less and cat, and how much is viewed using smart viewers/editors? I think the majority is viewed using the latter. Really though, he's got a good point. I'm typically viewing code in vi. I don't know why so many people have so many issues with tabs, they really aren't that difficult to work with and I think make life a little easier when working on code with multiple people. You can setup your environment to make tabs look like you want your code to look, your team members can do tabs their way, and in the end the indentation levels all work out fine. People want to fight tooth and nail over this debate. But its really not worth it. Get an editor that doesn't completely suck and you won't have problems. .c -- Carl J. Van Arsdall [EMAIL PROTECTED] Build and Release MontaVista Software -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs are EVIL *and* STUPID, end of discussion. (Re: Tabs versus Spaces in Source Code)
Andy Sy: Code with anything other than 8-space tabs will *NEVER* display properly using everyday unix utilities such as less and cat. less -xtabstop does what you want. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs are EVIL *and* STUPID, end of discussion. (Re: Tabs versus Spaces in Source Code)
Sybren Stuvel wrote: Andy Sy enlightened us with: Like I said, you'll *NEVER* get that fancy shmancy 'semantic indentation' idea to work properly in the most basic utilities which have the 8-space tabs assumption hardcoded in them. Fair enough. How much code is viewed with less and cat, and how much is viewed using smart viewers/editors? I think the majority is viewed using the latter. Just for the sake of completeness: cat file |sed 's/\t//g' less -x4 file vim ~/bin.cat #!/bin/sh cat $@ |sed 's/\t//g' :wq alias less='less -x4' -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs are EVIL *and* STUPID, end of discussion. (Re: Tabs versus Spaces in Source Code)
On Wed, 17 May 2006 17:28:26 GMT in comp.lang.python, Edward Elliott [EMAIL PROTECTED] wrote: Sybren Stuvel wrote: Andy Sy enlightened us with: Like I said, you'll *NEVER* get that fancy shmancy 'semantic indentation' idea to work properly in the most basic utilities which have the 8-space tabs assumption hardcoded in them. Fair enough. How much code is viewed with less and cat, and how much is viewed using smart viewers/editors? I think the majority is viewed using the latter. Just for the sake of completeness: cat file |sed 's/\t//g' That doesn't always work. If you don't see why, you don't understand my objection to TAB characters in text files. less -x4 file That will work. As long as the creator of file used four-space TABs, anyway... Regards, -=Dave -- Change is inevitable, progress is not. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs are EVIL *and* STUPID, end of discussion. (Re: Tabs versus Spaces in Source Code)
Dave Hansen wrote: That will work. As long as the creator of file used four-space TABs, anyway... That sentence has no meaning. There is no such thing as a four-space tab. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs are EVIL *and* STUPID, end of discussion. (Re: Tabs versus Spaces in Source Code)
Dave Hansen wrote: On Wed, 17 May 2006 17:28:26 GMT in comp.lang.python, Edward Elliott Just for the sake of completeness: cat file |sed 's/\t//g' That doesn't always work. If you don't see why, you don't understand my objection to TAB characters in text files. less -x4 file That will work. As long as the creator of file used four-space TABs, anyway... I fail to see why less 'will work' but cat 'doesn't always work'. The net effect of both is the same. Unless you're in some weird place that pipes aren't allowed, these should be equivalent: cat file |sed 's/\t//g' |less less -x4 file Now if you're talking about the conversion altering the data's semantics, that's a separate issue that has nothing to do with unix utilities and everything to do with the file formatting. In that case, I'll simply refer you to the rest of this thread for discussion. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs are EVIL *and* STUPID, end of discussion. (Re: Tabs versus Spaces in Source Code)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On May 17, 2006, at 8:46 PM, Edward Elliott wrote: Dave Hansen wrote: On Wed, 17 May 2006 17:28:26 GMT in comp.lang.python, Edward Elliott Just for the sake of completeness: cat file |sed 's/\t//g' That doesn't always work. If you don't see why, you don't understand my objection to TAB characters in text files. less -x4 file That will work. As long as the creator of file used four-space TABs, anyway... I fail to see why less 'will work' but cat 'doesn't always work'. The net effect of both is the same. Unless you're in some weird place that pipes aren't allowed, these should be equivalent: I don't think that cat is the problem, it's sed. The problem is that tabs take you to the next tab stop, they don't expand to a fixed number of spaces. Consider the strings \t\t, \t \t, and \t \t. With everything except one- or two-space tab settings (less -x1 or less -x2), the spaces haven't moved us past a tab stop, so the \t after them takes us to the same tab stop in all cases. Take care, Bill -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEa62XDJT2Egh26K0RAhFUAJ0WWgTRS570DsHAUl0oij47qNoIfgCgiVyV 9vZQUBAOspWLfuom2Scy4MY= =wmWa -END PGP SIGNATURE- -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs are EVIL *and* STUPID, end of discussion. (Re: Tabs versus Spaces in Source Code)
Edward Elliott wrote: Dave Hansen wrote: I fail to see why less 'will work' but cat 'doesn't always work'. The distinction is not in the choice of program, but in the way it is being used... The net effect of both is the same. Unless you're in some weird place that pipes aren't allowed, these should be equivalent: cat file |sed 's/\t//g' |less less -x4 file Nope. To demonstrate, I will use T to represent tab characters and S to represent spaces (I think this will be a lot easier to read): In a properly formatting program, with tabstops at intervals of 4: A= SSTSTdefSspam(self,Sfoo): STTbarS=S1/foo TTSTreturnSbar and B = TTdefSspam(self,Sfoo): barS=S1/foo TTTreturnSbar should render exactly the same (i.e. like the following): A=B= def spam(self, foo): bar = 1/foo return bar However, if we have tabstop set to 8 (the usual default), then they will render differently: A= def spam(self, foo): bar = 1/foo return bar B= def spam(self, foo): bar = 1/foo return bar (both are syntax errors, of course). Presumeably, the x option to less will correctly handle tabs (I didn't know about that -- thanks, BTW), but your sed substitution doesn't jump to the next tabstop when it hits a tab, it always adds a fixed number of spaces. So it mangles the code too: A= def spam(self, foo): bar = 1/foo return bar B= def spam(self, foo): bar = 1/foo return bar Now if you're talking about the conversion altering the data's semantics, that's a separate issue that has nothing to do with unix utilities and everything to do with the file formatting. In that case, I'll simply refer you to the rest of this thread for discussion. Now, of course, the data I provide is nasty, mean, poorly-formatted data, abhorable by space-zealots and tab-libertines alike (;-)), but the point is, unless you have set up your editor to syntax color spaces and tabs differently, you won't see the difference in the original editor. Cheers, Terry -- Terry Hancock ([EMAIL PROTECTED]) Anansi Spaceworks http://www.AnansiSpaceworks.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs are EVIL *and* STUPID, end of discussion. (Re: Tabs versus Spaces in Source Code)
William Studenmund wrote: The problem is that tabs take you to the next tab stop, they don't expand to a fixed number of spaces. Got it. You're talking about using tabs other than for initial line indentation on a source file. Yes, then tab expansion is not perfect. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs are EVIL *and* STUPID, end of discussion. (Re: Tabs versus Spaces in Source Code)
Terry Hancock wrote: Now, of course, the data I provide is nasty, mean, poorly-formatted data, abhorable by space-zealots and tab-libertines alike (;-)), but the point is, unless you have set up your editor to syntax color spaces and tabs differently, you won't see the difference in the original editor. Sure, mixed tabs and spaces were not part of my use case. -- Edward Elliott UC Berkeley School of Law (Boalt Hall) complangpython at eddeye dot net -- http://mail.python.org/mailman/listinfo/python-list
