www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: Adding D Editor Support

reply Brian Price <blprice61 yahoo.com> writes:
John A. De Goes Wrote:


 Hi,
 
 We're adding support for the D language to UNA (http://www.n-brain.net). The
Personal Edition has been released free of charge (down from $100).
 
 However, none of us have used D so we'd like a bit of help.
 
 We've added support (in dev version) to matching messages of the form:
 
 foo.d(5): Warning: silly variable name
 foo.d(5): Error: spelling error in variable name "foobir"
 
 Assuming this is correct, we'd like to proceed with adding commonly used
source code constructs, D idioms, and so forth. We call this 'source snippets'.
Each source snippet has a few letter textual key. Typing that key and invoking
the source snippet button inserts the snippet.
 
 So I'm soliciting for everyone's favorite source snippet.



Unsure how common this is but I find myself using the following handy construct
(assume module name can be inserted by {module}:

version({module}_test)
{
   import std.stdio;
   unittest 
  {
  }
  int main() 
  {
    return 0;
  }
}

This allows me to use the command line: dmd file1.d file2.d file3.d somelib.lib
-unittest -version=file1_test.

This results in only the tests from the requested file being generated in the
resulting executable.

Is it possible for custom snippets to be added by the user?

I look forward to trying out your IDE.  

Thanks,
Brian
Jun 14 2008
parent reply John A. De Goes <john.withoutspam. n-brain.net> writes:
Brian Price Wrote:

 This allows me to use the command line: dmd file1.d file2.d file3.d
somelib.lib -unittest -version=file1_test.



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?


 Is it possible for custom snippets to be added by the user?



Yes, indeed. I'd just like to ship with some decent snippets already built in.


 I look forward to trying out your IDE.  



That's great. Send us some feedback after you've used it for a while.

Regards,

John
Jun 14 2008
next sibling parent janderson <askme me.com> writes:
John A. De Goes wrote:

 Brian Price Wrote:

 This allows me to use the command line: dmd file1.d file2.d file3.d
somelib.lib -unittest -version=file1_test.



 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?
 



I would say yes.  Looking though the newsgroup, barely anyone uses the 
end of line syntax.



 Is it possible for custom snippets to be added by the user?



 Yes, indeed. I'd just like to ship with some decent snippets already built in.
 

 I look forward to trying out your IDE.  



 That's great. Send us some feedback after you've used it for a while.
 
 Regards,
 
 John
Jun 14 2008
prev sibling parent reply Georg Wrede <georg nospam.org> writes:
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.
Jun 19 2008
parent reply Ty Tower <tytower hotmail.com> writes:
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!
Jun 19 2008
next sibling parent Georg Wrede <georg nospam.org> writes:
Ty Tower wrote:

 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.



Next time you try to publish a book, you'll see. He absolutely hates any 
space usage that he doesn't understand the value of.


 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!



I know. Those books are written for (I don't seem to find the word).

I was talking about serious books.
Jun 20 2008
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Ty Tower" <tytower hotmail.com> wrote in message 
news:g3fg35$1t3l$1 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.
Jun 20 2008
parent reply Mike Parker <aldacron gmail.com> writes:
Nick Sabalausky wrote:

 "Ty Tower" <tytower hotmail.com> wrote in message 
 news:g3fg35$1t3l$1 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?



 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.
Jun 20 2008
parent Sean Kelly <sean invisibleduck.org> writes:
== Quote from Mike Parker (aldacron gmail.com)'s article

 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.



For my chapters, I found myself trying to produce compact examples
because doing so increased the likelihood that the example wouldn't
wrap to the following page... or push trailing description off to the
following page.  The rest is just personal preference however.  I very
much prefer example code that illustrates the point being discussed
with a minimum of unrelated stuff.


Sean
Jun 20 2008
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
== Quote from Ty Tower (tytower hotmail.com)'s article

 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!



This format is actually pulled from Public Speaking, where it has been
shown that listeners retain the material better if you basically do:

1. "This is what I'm going to tell you"
2. Tell them
3. "In summary, here is what I've just told you"

It's also good practice to limit an instructional lecture to no more than
3-4 main points.  Done right, I think this is actually a very good format,
even in a book.  "The Pragmatic Programmer," for example, follows this
format and it's one of the best programming books I've ever read, and
also one of the most concise.


Sean
Jun 20 2008