March 06, 2015
On 3/5/2015 7:15 PM, Brian Schott wrote:
> You probably feel that way because tabs are better. dfmt only defaults to spaces
> because that's what's in the Phobos style guide.

Spaces are used in Phobos because no two tools agree on what the tab size should be.
March 06, 2015
On 3/5/2015 1:04 AM, Russel Winder via Digitalmars-d-announce wrote:
> It would be good if the D implemented D parser were though. Parsing to
> create an AST is needed for many things. If each tool in the tool
> chain implements it's own… it just seems wrong.
>

True, but on the other hand, a D lexer and parser are pretty simple.
March 06, 2015
On 3/3/2015 3:03 PM, Brian Schott wrote:
> dfmt works by re-using my existing lexer and parser. The parser is run on the
> code first so that the formatting step knows a few things like the difference
> between the binary and unary forms of "*". Line splitting is figured out using a
> badly mangled version of A*.

How are comments handled?
March 06, 2015
On Friday, 6 March 2015 at 09:40:07 UTC, Walter Bright wrote:
> How are comments handled?

The source code makes a DC 15 wisdom save, if it fails then the comments get distributed randomly.

The serious answer is that there's a lot of special casing that I'm still trying to figure out.
March 06, 2015
On Friday, 6 March 2015 at 09:39:13 UTC, Walter Bright wrote:
> True, but on the other hand, a D lexer and parser are pretty simple.

Did you mean "simple compared to C++"? I remember having to report/fix a LOT of bugs in the language specification and explore the DMD front end source code to get to where I am now.

March 06, 2015
On Fri, 2015-03-06 at 01:37 -0800, Walter Bright via Digitalmars-d-announce wrote:
> On 3/5/2015 7:15 PM, Brian Schott wrote:
> > You probably feel that way because tabs are better. dfmt only
> > defaults to spaces
> > because that's what's in the Phobos style guide.
> 
> Spaces are used in Phobos because no two tools agree on what the tab size should be.

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.

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

March 06, 2015
On Fri, 2015-03-06 at 09:48 +0000, Brian Schott via Digitalmars-d-announce wrote:
> On Friday, 6 March 2015 at 09:40:07 UTC, Walter Bright wrote:
> > How are comments handled?
> 
> The source code makes a DC 15 wisdom save, if it fails then the comments get distributed randomly.

But with a d4, d6, d8, d10, d12, d20, d100?

> The serious answer is that there's a lot of special casing that  I'm still trying to figure out.

I prefer the previous answer :-)
-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

March 06, 2015
On Friday, 6 March 2015 at 09:39:13 UTC, Walter Bright wrote:
> On 3/5/2015 1:04 AM, Russel Winder via Digitalmars-d-announce wrote:
>> It would be good if the D implemented D parser were though. Parsing to
>> create an AST is needed for many things. If each tool in the tool
>> chain implements it's own… it just seems wrong.
>>
>
> True, but on the other hand, a D lexer and parser are pretty simple.

I'd like to hear your definition of simple.
March 06, 2015
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;
-}

  - 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___________^

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_________________________^

--Ben

[1]File size savings are negligible.
March 06, 2015
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@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder