dfmt 0.1.0

[Russel Winder via Digitalmars-d-announce]

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
declarations.

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.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-announce/attachments/20150306/7ec6083f/attachment.sig>