On Fri, 2015-03-06 at 09:54 -0500, Ben Boeckel via
Digitalmars-d-announce wrote:
> On Fri, Mar 06, 2015 at 10:31:29 +0000, Russel Winder via 
> Digitalmars-d-announce wrote:
> > That is the whole point of using tabs for indent, you can chose the 
> > indent amount: I tend to use 20ex.
> > 
> > Remember a tab is not a number of spaces, it is semantic markup. Using 
> > spaces is a low-level hack founded on a lack of separation of concerns 
> > and abstraction.
> The problem with tabs, IMO, are the following:
>   - don't look right in patches (notice the different alignment of
>     indented lines versus lines without any):
> -int foo(int bar) {
> -     return bar;
> -}
>     versus (assuming 8 space indents):
> -int foo(int bar) {
> -        return bar;
> -}

Is your point that in this case they have rendered identically?

>   - I have yet to see an editor properly do tab-for-indent with proper
>     space-for-alignment without manual management:
>       int my_long_function_name(int bar,
>                                 int baz)
> ^__tab_^^_______spaces___________^

But, for me anyway, the fundamental flaw here is the idea of alignment.
Find a style that eliminates all this alignment malarkey.

I really dislike the Go obsession with block style alignment of

The core problem here is teletype, monospace font thinking. Using a
proper proportional font for you code and you rapidly lose the need for
all this alignment stuff.

<Real point but expressed as a bit of a troll, mostly to expose that
this is likely a bikeshed issue.>

> By the way, this is *wrong* because tabs now have a defined size (8
> here) which defeats the only (tangible[1]) advantage they have:
>       int my_long_function_name(int bar,
>                                 int baz)
> ^__tab_________________________^

In a real editor there is no hard line break, no need for this form of
indentation. Should a line be too long for the rendering area either
viewport or syntax directed soft line wrap are used. Having overflow is
mixing content with rendering.

> --Ben
> [1]File size savings are negligible.

Indeed, no argument with that point.

Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to