dfmt 0.1.0

[Ben Boeckel via Digitalmars-d-announce]

On Fri, Mar 06, 2015 at 19:55:10 +0000, Russel Winder via Digitalmars-d-announce wrote:
> On Fri, 2015-03-06 at 09:54 -0500, Ben Boeckel via
> Digitalmars-d-announce wrote:
> > -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?

Well it is now more apparent with more quoting. It now appears that the
first block is using 3-space indents while the bottom looks just fine
even with the quote markers.

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

Well, when that means you're going to have absurdly long lines to deal
with in anything other than your definition "real" editors (and I've
never seen one which fits your definition).

> I really dislike the Go obsession with block style alignment of
> declarations.

I won't say I'm a fan of it indiscriminently, but if it's that or
200+-character lines, I'll chop argument lists up a bit to fit something
more reasonable.

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

And I find that monospace fonts tend to make it much easier to tell the
difference between 'l', '1', and 'I'. Not so important in English, but
it can be all the difference in code.

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

You're making assumptions about the features of your users' editors.
These features are not trivial to implement and this basically requires
things like pygments and other tools used to render code to the web with
all kinds of logic to handle dynamic viewports of the shown code. IMO,
it is even worse than putting #vim:, #kate:, or emacs formatting
directives in your code since it is implicit.

Personally, I use Vim because it works similarly for all uses. I don't
know what I'd do if I had to work with a different editor for each
language I work with.

--Ben