Hi everyone,

No, the entire formatting engine is NOT finished yet. :P
Anyway I've created a good compromise solution between releasing
stuff early and having a fairly nice formatting result:

I just let the indenting engine calculate the indents of all
lines of the code - and fix all the incorrect indents afterwards.
It works quite fast & reliable(?) - I hope it won't throw very
often + you don't have to worry about resetting your code to an
earlier state via [Ctrl+Shift][Z]

Indenting only parts of the code is possible either! - So you
don't have to worry about your entire code getting messed up
probably ;)


More info @ http://mono-d.alexanderbothe.com

Issues: https://github.com/aBothe/Mono-D/issues

Thanks Alex, even though I don't use auto-formatting (I never did like that).

On Monday, 21 January 2013 at 21:32:38 UTC, F i L wrote:
> Thanks Alex, even though I don't use auto-formatting (I never did like that).

I use it rarely either - but some others asked whether I could do this - and now there it is :)

On Monday, 21 January 2013 at 21:35:11 UTC, alex wrote:
> On Monday, 21 January 2013 at 21:32:38 UTC, F i L wrote:
>> Thanks Alex, even though I don't use auto-formatting (I never did like that).
>
> I use it rarely either - but some others asked whether I could do this - and now there it is :)

Lack of auto-formatter was the reason I stopped using Mono-D some time ago :) Awesome update, good luck with this!

On Tuesday, 22 January 2013 at 10:26:21 UTC, mist wrote:
> On Monday, 21 January 2013 at 21:35:11 UTC, alex wrote:
>> On Monday, 21 January 2013 at 21:32:38 UTC, F i L wrote:
>>> Thanks Alex, even though I don't use auto-formatting (I never did like that).
>>
>> I use it rarely either - but some others asked whether I could do this - and now there it is :)
>
> Lack of auto-formatter was the reason I stopped using Mono-D some time ago :) Awesome update, good luck with this!

Uhm..what is an auto-formatter in your eyes? Automatic formatting
when you typed a '}' for instance?
Or just the explicit possibility to let a program format your
code?

I mean, once the code got indented correctly, why should it ever
be passed through a formatter again? Just to see that it's
actually been indented correctly? Hmm..

I always define project code style policies in Eclipse code style settings and run auto-format (Ctrl+Shift+F) on new code always before commiting to ensure my nasty personal preferences have not slipped out of subconscious. It also converts all whitespaces consistently to match project settings and sometimes I forget to setup tab->space autoreplacement for external editors.

In-place formatting is not that important for me.

On Tuesday, 22 January 2013 at 14:44:15 UTC, alex wrote:
> On Tuesday, 22 January 2013 at 10:26:21 UTC, mist wrote:
>> On Monday, 21 January 2013 at 21:35:11 UTC, alex wrote:
>>> On Monday, 21 January 2013 at 21:32:38 UTC, F i L wrote:
>>>> Thanks Alex, even though I don't use auto-formatting (I never did like that).
>>>
>>> I use it rarely either - but some others asked whether I could do this - and now there it is :)
>>
>> Lack of auto-formatter was the reason I stopped using Mono-D some time ago :) Awesome update, good luck with this!
>
> Uhm..what is an auto-formatter in your eyes? Automatic formatting
> when you typed a '}' for instance?
> Or just the explicit possibility to let a program format your
> code?
>
> I mean, once the code got indented correctly, why should it ever
> be passed through a formatter again? Just to see that it's
> actually been indented correctly? Hmm..

On Tuesday, 22 January 2013 at 15:54:46 UTC, mist wrote:
> I always define project code style policies in Eclipse code style settings and run auto-format (Ctrl+Shift+F) on new code always before commiting to ensure my nasty personal preferences have not slipped out of subconscious. It also converts all whitespaces consistently to match project settings and sometimes I forget to setup tab->space autoreplacement for external editors.
>
> In-place formatting is not that important for me.
>

So that's the exact thing I'm trying to implement: To define an IDE- or project-wide formatting policy and let this control the code style.
Let's see how far I can do it :)

On 21/01/2013 21:14, alex wrote:
> Hi everyone,
>
> No, the entire formatting engine is NOT finished yet. :P
> Anyway I've created a good compromise solution between releasing
> stuff early and having a fairly nice formatting result:
>
> I just let the indenting engine calculate the indents of all
> lines of the code - and fix all the incorrect indents afterwards.
> It works quite fast & reliable(?) - I hope it won't throw very
> often + you don't have to worry about resetting your code to an
> earlier state via [Ctrl+Shift][Z]
>
> Indenting only parts of the code is possible either! - So you
> don't have to worry about your entire code getting messed up
> probably ;)
>
>
> More info @ http://mono-d.alexanderbothe.com
>
> Issues: https://github.com/aBothe/Mono-D/issues

That's a lot of continuing nice work coming out from there, impressive!

BTW, something I've been meaning to ask. I see that in Mono-D you've developed a hand-written D parser. How long did it take you to write that? Did you test it extensively or not so much?

I'm embarking on that same task in Java, for DDT, and wondering how long it will take to build a quality parser. So far, it doesn't seem writing the actual parser will take that long, but writing extensive tests for it is seeming exceedingly complicated (or just lengthy and time-consuming). I'm usually a big proponent of TDD, but when writing a lot of tests starts to take a lot of time compared to the code being tested (in this case, maybe 1.5 times the effort/time of the code being tested), I'm not so certain it's the right call to spend so much time writing tests...

-- 
Bruno Medeiros - Software Engineer

On 2013-01-24 14:12, Bruno Medeiros wrote:

> That's a lot of continuing nice work coming out from there, impressive!
>
> BTW, something I've been meaning to ask. I see that in Mono-D you've
> developed a hand-written D parser. How long did it take you to write
> that? Did you test it extensively or not so much?
>
> I'm embarking on that same task in Java, for DDT, and wondering how long
> it will take to build a quality parser. So far, it doesn't seem writing
> the actual parser will take that long, but writing extensive tests for
> it is seeming exceedingly complicated (or just lengthy and
> time-consuming). I'm usually a big proponent of TDD, but when writing a
> lot of tests starts to take a lot of time compared to the code being
> tested (in this case, maybe 1.5 times the effort/time of the code being
> tested), I'm not so certain it's the right call to spend so much time
> writing tests...

How about reusing the one in VisualD, it's written in D? Sure it's a bit more work since it's not written in a Java compatible language but it might be worth it.

-- 
/Jacob Carlborg

On Thursday, 24 January 2013 at 13:12:31 UTC, Bruno Medeiros
wrote:
> On 21/01/2013 21:14, alex wrote:
>> Hi everyone,
>>
>> No, the entire formatting engine is NOT finished yet. :P
>> Anyway I've created a good compromise solution between releasing
>> stuff early and having a fairly nice formatting result:
>>
>> I just let the indenting engine calculate the indents of all
>> lines of the code - and fix all the incorrect indents afterwards.
>> It works quite fast & reliable(?) - I hope it won't throw very
>> often + you don't have to worry about resetting your code to an
>> earlier state via [Ctrl+Shift][Z]
>>
>> Indenting only parts of the code is possible either! - So you
>> don't have to worry about your entire code getting messed up
>> probably ;)
>>
>>
>> More info @ http://mono-d.alexanderbothe.com
>>
>> Issues: https://github.com/aBothe/Mono-D/issues
>
> That's a lot of continuing nice work coming out from there, impressive!
>
> BTW, something I've been meaning to ask. I see that in Mono-D you've developed a hand-written D parser. How long did it take you to write that? Did you test it extensively or not so much?
>
> I'm embarking on that same task in Java, for DDT, and wondering how long it will take to build a quality parser. So far, it doesn't seem writing the actual parser will take that long, but writing extensive tests for it is seeming exceedingly complicated (or just lengthy and time-consuming). I'm usually a big proponent of TDD, but when writing a lot of tests starts to take a lot of time compared to the code being tested (in this case, maybe 1.5 times the effort/time of the code being tested), I'm not so certain it's the right call to spend so much time writing tests...

Are you making use of JavaCC or ANTLR?