Removing D embedded in HTML feature

[Jim Hewes]

"Bjoern" <nanali at nospam-wanadoo.fr> wrote in message 
news:fsouvv$2r1d$1 at digitalmars.com...
>
> Please keep it.
>
> I am conviced that "text only" is not enough for next generation code 
> editors. a few examples :
>
> a database application could embedd an Entity Relationship model. This 
> could be a simple static graphic, or even an interactive live model which 
> generates D code. (using java applets, ActiveX, ...)
>
> D has strong OOP features, why not having an interactive UML modeler 
> within the code.
>
> D has builtin profiler support, why not embedding a charts, coloring time 
> critical sections.
>
> extented Documentation support
>
> I am convinced that, once the first HTML base D code-editor is released, 
> several new, fantastic ideas will be born.
>
> I guess java applets can be used as code generators, code watcher (safeD, 
> without using the compiler) ....
>
> I thinking about : "how a next generation code editor should look like" 
> for quit a while and hope to implement an HTML based (or hypertext based 
> in general) Editor for D for use in my IDE.
>
> Bjoern
>

Although I keep an eye on these newsgroups and I think D looks nice, I'm not 
currently using it. So I wouldn't want to vote on the HTML thing. But I 
agree about code editors.

I'm kind of surprised, software as gotten to the advanced level it has over 
the past 20 years or so, and we're still writing source code in ASCII text 
files. I'm using Visual Studio 2005/2008 to do C++ and C# and it's a great 
achievement. But we're still using ASCII text files.
For years I've wanted to draw block diagrams and flow charts right in the 
code to document what's going on. How great would it be if you could use 
Microsoft Word to write code with and also draw your diagrams alongside? You 
could use bold and italics formatting to emphasize important code. Change 
the size of text, add tables, etc. The compiler doesn't have to understand 
MS-Word format. Rather, the editor (or some other utility) could just export 
the ASCII for the compiler's consumption. Perhaps better, create a standard 
file format for code that can handle graphics and other documentation. Then 
to avoid the step of exporting the raw ASCII, you can have the file format 
store the actual code in a separate section that's easy for compilers to 
find. Then compilers can navigate to that section of the file and ignore 
everything else. I don't think it's too much to expect standards for source 
code files, given that standardization seems to have moved along for things 
like the C++ library and C++98 and 0x. </rant>

Jim Hewes