Adding D Editor Support

[Nick Sabalausky]

"Ty Tower" <tytower at hotmail.com> wrote in message 
news:g3fg35$1t3l$1 at digitalmars.com...
> Georg Wrede Wrote:
>
>> John A. De Goes wrote:
>> > Looks great! I'll add it to the templates. All the examples so far
>> > have used block-aligned styling:
>> >
>> > a { }
>> >
>> > In Java, for example, the most popular convention by far is to place
>> > the opening brace at the end of the preceding line. Are the examples
>> > I've seen representative of the more popular conventions within the D
>> > community?
>>
>> Most of programming examples you can see in textbooks (and of course on
>> many web sites) use the brace-at-end-of-line. People who've learnt to
>> program from them get used to the "look", and then of course perceive it
>> as prettier.
>>
>> Now, there are a couple of (rational) reasons for this custom. One is,
>> in short examples it is nice to have the entire code snippet as short as
>> possible, so that you can view some of the explaining text both before
>> and after the code snippet at a glance.
>>
>> The other reason is, in textbooks there's a scarcity of dead wood. The
>> publisher has to enforce brevity, and this is (from his POV) an
>> unobtrusive way to achieve much of it.
>>
>>
>> In an environment where yuou aren't constrained by space, it soon
>> becomes practice to use the braces-on-own-lines convention. It uses more
>> space, but if your screen has a resolution that allows it, then you
>> don't care.
>>
>> Code with braces on their own lines is more manageable. One can grep for
>> opening/closing braces, programs get clearer to grasp at a glance, etc.
>> (Yes I know, now 500 people are going to contest my position. All I can
>> say is, what one is used to looks clearer and more natural. But I'm
>> talking a bigger perspective here.)
>>
>> On a 25-line monitor I'd use the brace-at-end convention, too.
>>
>> Oh, and the end result: I see no significan difference between C, C++,
>> Java, and a few other languages, versus D, in the choice of bracing.
>> It's mostly just a programmer preference. And both are used.
>
>
> Quote from George
> "The other reason is, in textbooks there's a scarcity of dead wood. The
> publisher has to enforce brevity, and this is (from his POV) an
> unobtrusive way to achieve much of it."
>
> Well George if this is good and valid info I will eat my hat.
> Puts the credibility of the rest of your writing in doubt.
>
> Pick up most programming texts and they are crammed with
> "Here is what this chapter will teach you"
> "Here is a load of unnecessary garbage"
> "Here is the guts of it"
> "Here is what you have learnt in this chapter"
> "Here's what we will cover in the next chapter"
>
> and so on , so there is not much care about brevity that I have seen!

You know, that's actually an interesting point. I wouldn't put it quite so 
harshly, but I have seen a lot of programming books that do have a lot of 
what I would consider to be fluff (and I don't mean sidebar text (that can 
be interesting), but rather some of the things Ty points out. For instance, 
you can see what a chapter covers just by skimming through it). So in a way, 
it does seem a little odd that there tends to be fuss over code length (I 
can understand limited horizontal space though) when there's all of that 
other, IMHO, redundant/superfluous stuff.