Adding D Editor Support

[Mike Parker]

Nick Sabalausky wrote:
> "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. 
> 
> 

For 'Learn to Tango with D', we didn't have anyone telling to shorten 
example code. We /were/ working within pretty tight constraints as far 
as page limit (the First Press series of books are intended to be 
short). But code size was never an issue. The only guideline for code 
was for formatting. Each line needed to be within a fixed-width.

Frequently, they asked us to add more info to a chapter. They generally 
wanted the opening paragraphs to summarize the contents. I expected them 
to ask for a summary at the end of each chapter as well, since that 
format is so common in tech books, but they never did.