Date: Thu, 16 Apr 2009 17:57:42 +0200 From: deeptech71@gmail.com To: freebsd-chat@freebsd.org Subject: Re: My whitespace style Message-ID: <49E75576.8070102@gmail.com> In-Reply-To: <87bpqytmc7.fsf@kobe.laptop> References: <49E2FBE2.8020305@gmail.com> <20090413140912.GC29833@Grumpy.DynDNS.org> <49E51B42.2060405@gmail.com> <320BA0A7-C5E0-40E5-97F9-F19BF1C61B29@hiwaay.net> <49E5670C.8070708@gmail.com> <87bpqytmc7.fsf@kobe.laptop>
next in thread | previous in thread | raw e-mail | index | archive | help
Giorgos Keramidas wrote:
> On Wed, 15 Apr 2009 06:48:12 +0200, deeptech71@gmail.com wrote:
>> Could you please give me a (preferrably widely used) example of
>> columnizing calls which cross different levels of indentation?
>
> It's not so uncommon as it may initially seem...
>
> I've seen switch() cases in several programs indented like this:
>
> switch (value) {
> case SOME_CONSTANT_NAME: do_stuff_here(); break;
> case ANOTHER_CONSTANT_NAME: do_some_other_stuff(); break;
> default: default_stuff(); break;
> }
I only see level 1 indentation, not more, not less.
Oliver Fromme wrote:
> Matthew D. Fuller wrote:
> > Only if you abuse tabs for alignment. Indentation is not alignment.
> > It's a pity that the two get conflated and everybody ends up treating
> > them the same, so that advocating tab indentation is read as
> > advocating tab alignment (even by proponents of tab indentation).
>
> The problem is that many (most? all?) editors cannot easily
> be configured to differentiate between them, i.e. insert
> literal ASCII tabs characters when the <Tab> key is pressed
> for indentation, and insert ASCII spaces when the <Tab> key
> is pressed for alignment. *And* treat the alignment spaces
> transparently like tabs, just like the indentation spaces.
>
> That's probably not easy to implement, and it gets really
> messy when you edit the line, remove or insert stuff between
> the alignment spaces and the indetation tabs and so on.
> Then suddenly alignment can become indentation, and vice
> versa. The editor would then have to transparently convert
> existing ASCII tab characters to spaces or vice versa.
> This is a huge can of worms.
>
> That's another good reason to let the old ASCII tab die and
> rest in peace (or "lost in space" ... ok, bad pun).
In this and other posts you only give reason to kill off the space, not
the tab. If two things conflict, which is wrong is for me to decide, not
you. :) Seriously, let's devise a reason why one should die.
Yes, it's hard to implement an editor which controls retarded mixes of
tabs and spaces. But generally it's hard to implement an editor which
controls retarded of any ASCII character. So let's only consider
"well-formed" files. For such files, my whitespace style applies: if
indentation is width-critical, use spaces, otherwise (like C source) use
tabs precisely for indentation. What do you want from not well-formed files?
So neither should die, rather the people who voluntarity misuse them.
[One more time, if there were no spaces, there would be no problems. :)]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49E75576.8070102>