www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Removing D embedded in HTML feature

reply Walter Bright <newshound1 digitalmars.com> writes:
Scott suggested this be removed for D 2.0. Is anyone at all using it, or 
have plans to use it, or can make a good case for keeping it?

http://www.digitalmars.com/d/2.0/html.html
Mar 30 2008
next sibling parent BCS <ao pathlink.com> writes:
Reply to Walter,


 Scott suggested this be removed for D 2.0. Is anyone at all using it,
 or have plans to use it, or can make a good case for keeping it?
 
 http://www.digitalmars.com/d/2.0/html.html
 


Dump it!
Mar 30 2008
prev sibling next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:fsos4e$2j25$2 digitalmars.com...

 Scott suggested this be removed for D 2.0. Is anyone at all using it, or 
 have plans to use it, or can make a good case for keeping it?

 http://www.digitalmars.com/d/2.0/html.html


Dump it.  Or, just make it a compiler feature that DMD provides, but don't 
include it in the language spec.
Mar 30 2008
prev sibling next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Walter Bright wrote:


 Scott suggested this be removed for D 2.0. Is anyone at all using it, or
 have plans to use it, or can make a good case for keeping it?
 
 http://www.digitalmars.com/d/2.0/html.html


Good riddance.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango
Mar 30 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Lars Ivar Igesund wrote:

 Good riddance.


I guess it's not getting much love <g>.
Mar 30 2008
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter Bright Wrote:

 Scott suggested this be removed for D 2.0. Is anyone at all using it, or 
 have plans to use it, or can make a good case for keeping it?
 http://www.digitalmars.com/d/2.0/html.html


- I like the idea of literate programming, where you can put the code between
comments. I have seen many tutorials on Haskell where you can compile the page,
that is filled with textual (html) explanations.
- But I think there can be ways to do something similar "out" of the compiler.
We can think about this (little) problem right now.
- There is something that currently is missing from the compiler that is about
1000 times more useful than that D embedded in HTML feature, that is the basic
functionality of the "bud" program, that is the compiler to find by itself the
modules to compile.
- Probably there are other features currently present in D that people may be
glad to drop, you can ask people to list them :-)

Bye,
bearophile
Mar 30 2008
prev sibling next sibling parent reply Bjoern <nanali nospam-wanadoo.fr> writes:
Walter Bright schrieb:

 Scott suggested this be removed for D 2.0. Is anyone at all using it, or 
 have plans to use it, or can make a good case for keeping it?
 
 http://www.digitalmars.com/d/2.0/html.html


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
Mar 30 2008
next sibling parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
In practice, none of these solutions would use HTML.  They would all use 
XML, zip-based packages (like the open office formats), or separate 
side-by-side files (like ASP.NET.)

HTML is the wrong way to solve those problems.  XML has CDATA, which 
makes it quite a lot easier to write actual code inside the XML file. 
All of these things could (and would) be formatted with a xslt 
stylesheet, which means the data is available for other things (Flash 
charts, js coolness, or even just interpretation by 3rdparty tools.)

XHTML might be "the right way" in some ways, but it hasn't really gained 
actual traction much yet (most browsers do not actually read XHTML, so 
the benefits of CDATA are unavailable.)

-[Unknown]


Bjoern wrote:

 Walter Bright schrieb:

 Scott suggested this be removed for D 2.0. Is anyone at all using it, 
 or have plans to use it, or can make a good case for keeping it?

 http://www.digitalmars.com/d/2.0/html.html


 
 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
Mar 30 2008
prev sibling next sibling parent reply BCS <ao pathlink.com> writes:
Reply to bjoern,


 Walter Bright schrieb:
 

 Scott suggested this be removed for D 2.0. Is anyone at all using it,
 or have plans to use it, or can make a good case for keeping it?
 
 http://www.digitalmars.com/d/2.0/html.html
 


 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
 


I'm working with some people that are working on one of the most advanced 
abstraction systems I know of. There goal is to push abstraction as far as 
possible and the conclusion after several years of playing with different 
approaches (much of it trying to build a UI that lets people work with the 
abstractions) is that abstractions and fancy UI's don't mix because as soon 
as I abstract above what the UI knows, the UI breaks. Your time will be better 
spent building these tools outside D (code generators) or inside D (meta 
programming). IMNSHO, trying to interleave the D code and external abstractions 
is a waste of time.
Mar 30 2008
parent "Craig Black" <cblack ara.com> writes:
"BCS" <ao pathlink.com> wrote in message 
news:55391cb32b1988ca60bce34bf4a0 news.digitalmars.com...

 Reply to bjoern,


 Walter Bright schrieb:


 Scott suggested this be removed for D 2.0. Is anyone at all using it,
 or have plans to use it, or can make a good case for keeping it?

 http://www.digitalmars.com/d/2.0/html.html


 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


 I'm working with some people that are working on one of the most advanced 
 abstraction systems I know of. There goal is to push abstraction as far as 
 possible and the conclusion after several years of playing with different 
 approaches (much of it trying to build a UI that lets people work with the 
 abstractions) is that abstractions and fancy UI's don't mix because as 
 soon as I abstract above what the UI knows, the UI breaks. Your time will 
 be better spent building these tools outside D (code generators) or inside 
 D (meta programming). IMNSHO, trying to interleave the D code and external 
 abstractions is a waste of time.


And it overcomplicates the compiler implementation.  It is very important 
that D compilers be easy to implement.
Mar 31 2008
prev sibling parent reply "Jim Hewes" <jhewes sysviewtech.com> writes:
"Bjoern" <nanali nospam-wanadoo.fr> wrote in message 
news:fsouvv$2r1d$1 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 

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
Apr 02 2008
next sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
Jim Hewes wrote:

 
 "Bjoern" <nanali nospam-wanadoo.fr> wrote in message 
 news:fsouvv$2r1d$1 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 

 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


1. No formatting in code. Syntax highlighting is fine, but that's an 
end-user thing. Tabs versus spaces should be an end-user thing, too. (I 
just dealt with a professor distributing SQL in Powerpoint. 32pt Comic 
Sans. Ugh.)

2. Keep the code as portable as possible. UTF8 for the win. Not just 
because the code has to travel between computers and operating systems, 
but because people fight wars over editors.

3. It already takes me five minutes to check out a fresh copy of my 
projects at work. If the files contained formatting data, they'd be a 
fair bit larger, which would increase that time. That would be annoying.

4. UML is terrible. Don't bring it into source code.

Now, if you wanted tables and such in comments, fine. I think they'd be 
overused and annoying, but I can see the utility.
Apr 02 2008
next sibling parent reply Jussi Jumppanen <jussij zeusedit.com> writes:
Christopher Wright Wrote:


 3. It already takes me five minutes to check out a 
 fresh copy of my projects at work. If the files 
 contained formatting data, they'd be a fair bit 
 larger, which would increase that time. That would 
 be annoying.


And adding binary files to the version control would 
put an end to any meaningful file difference/change
history feature, making the change control pretty 
much unworkable.
Apr 02 2008
next sibling parent Christopher Wright <dhasenan gmail.com> writes:
Jussi Jumppanen wrote:

 Christopher Wright Wrote:
 

 3. It already takes me five minutes to check out a 
 fresh copy of my projects at work. If the files 
 contained formatting data, they'd be a fair bit 
 larger, which would increase that time. That would 
 be annoying.


 
 And adding binary files to the version control would 
 put an end to any meaningful file difference/change
 history feature, making the change control pretty 
 much unworkable.


Subversion does okay with xml, and I imagine that goes for most RCSs. 
But xml tends to be verbose if it's readable, which led to ODF using 
zipped xml files, which brings us back to binary files.
Apr 03 2008
prev sibling next sibling parent "Bruce Adams" <tortoise_74 yeah.who.co.uk> writes:
On Thu, 03 Apr 2008 06:18:53 +0100, Jussi Jumppanen <jussij zeusedit.com>  
wrote:


 Christopher Wright Wrote:


 3. It already takes me five minutes to check out a
 fresh copy of my projects at work. If the files
 contained formatting data, they'd be a fair bit
 larger, which would increase that time. That would
 be annoying.


 And adding binary files to the version control would
 put an end to any meaningful file difference/change
 history feature, making the change control pretty
 much unworkable.


No. It just means your version control system has to understand the file  
format or support
the custom filters allowing it to do so. The only reason you can't diff  
word documents
(diff them well that is) is the proprietry file format. Still that said, I  
don't know
of many VC systems that support custom file formats that way.
Apr 07 2008
prev sibling parent "Jim Hewes" <jhewes sysviewtech.com> writes:
"Jussi Jumppanen" <jussij zeusedit.com> wrote in message 
news:ft1pbt$1j3d$1 digitalmars.com...

 Christopher Wright Wrote:


 3. It already takes me five minutes to check out a
 fresh copy of my projects at work. If the files
 contained formatting data, they'd be a fair bit
 larger, which would increase that time. That would
 be annoying.


 And adding binary files to the version control would
 put an end to any meaningful file difference/change
 history feature, making the change control pretty
 much unworkable.


Normally, you inspect file differences using a special differencing utility 
such WinMerge, true? Nothing to do with the version control. So why can't 
that utility understand a new standard file format? Or, at least know how to 
find the raw code within the file. A touted feature of version control 
systems like Subversion and Mercurial is that they can handle binary files. 
But the graphics need not be binary; they can be vector drawings and could 
be stored in XML format.

I'd rather not be satified with any argument that says we can never have 
anything more than ASCII because all of our existing tools understand ASCII, 
and we can never build new tools.

Jim
Apr 10 2008
prev sibling parent reply "Jim Hewes" <jhewes sysviewtech.com> writes:
"Christopher Wright" <dhasenan gmail.com> wrote in message 
news:ft1mq1$1c68$1 digitalmars.com...

 1. No formatting in code. Syntax highlighting is fine, but that's an 
 end-user thing. Tabs versus spaces should be an end-user thing, too. (I 
 just dealt with a professor distributing SQL in Powerpoint. 32pt Comic 
 Sans. Ugh.)

 2. Keep the code as portable as possible. UTF8 for the win. Not just 
 because the code has to travel between computers and operating systems, 
 but because people fight wars over editors.

 3. It already takes me five minutes to check out a fresh copy of my 
 projects at work. If the files contained formatting data, they'd be a fair 
 bit larger, which would increase that time. That would be annoying.

 4. UML is terrible. Don't bring it into source code.

 Now, if you wanted tables and such in comments, fine. I think they'd be 
 overused and annoying, but I can see the utility.


I take it you disagree with me. :-) Anyway, I'm not sure I was clear.

1. There would be no formatting in code that was fed to the compiler. 
Appearance of code is personal taste. I find it annoying to look at code 
where the opening braces always are on the right. But a lot of people do it. 
If you don't want to see code as comic sans serif, then set the preference 
in your editor to show all code in courier. If some programmer formatted a 
comment or a line of code in bold because he thought it was important and 
should stand out, and you don't want to see any bold, then set your editor 
to not show any bold.

2. I think it should be portable, too. I just don't think ASCII or UTF8 is 
the only thing that can ever be portable. Code is currently portable only 
because everyone has agreed on a standard called ASCII. You can't see source 
code on a disk with your eyes. You need a special tool called a text editor, 
whether it's vi, emacs, or Windows notepad. If everyone agreed on another 
type of standard file that could hold more than just ASCII, I don't see the 
conceptual difference. (Perhaps it would be PDF) In any case, you could 
always export just the code for the luddites. :-)

3.  But you still need to create and maintain documentation for your code 
right? Where is that kept? In a separate place than the code? You need to 
modify that? Do you keep revisions of that documentation that stays with the 
code?

4. I didn't suggest UML. I just want to add vector diagrams, drawings, 
flowcharts, links and other forms of visual documentation. I want to edit 
them and keep them together with the source. Sure I can use Doxygen to add 
 param and  returns in the source. But then when I look at the source, I see 
the ugly  param and  returns. If I want to see nice formatting, I need to go 
look at the HTML output which is whole separate thing. And then when I'm 
looking at the HTML output in the browser, I can't edit code there. Why can't 
it be together?

Jim
Apr 10 2008
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Jim Hewes wrote:

 4. I didn't suggest UML. I just want to add vector diagrams, drawings, 
 flowcharts, links and other forms of visual documentation. I want to 
 edit them and keep them together with the source. Sure I can use Doxygen 
 to add  param and  returns in the source. But then when I look at the 
 source, I see the ugly  param and  returns. If I want to see nice 
 formatting, I need to go look at the HTML output which is whole separate 
 thing. And then when I'm looking at the HTML output in the browser, I 
 can't edit code there. Why can't it be together?


That's one of the goals of DDoc -- to be (generally) human-readable 
without a lot of formatting. Not sure how successful it is at that, but 
I think it's a step up from Doxygen and Javadoc:

http://www.digitalmars.com/d/2.0/ddoc.html
Apr 10 2008
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Robert Fraser wrote:

 Jim Hewes wrote:

 4. I didn't suggest UML. I just want to add vector diagrams, drawings, 
 flowcharts, links and other forms of visual documentation. I want to 
 edit them and keep them together with the source. Sure I can use 
 Doxygen to add  param and  returns in the source. But then when I look 
 at the source, I see the ugly  param and  returns. If I want to see 
 nice formatting, I need to go look at the HTML output which is whole 
 separate thing. And then when I'm looking at the HTML output in the 
 browser, I can't edit code there. Why can't it be together?


 
 That's one of the goals of DDoc -- to be (generally) human-readable 
 without a lot of formatting. Not sure how successful it is at that, but 
 I think it's a step up from Doxygen and Javadoc:
 
 http://www.digitalmars.com/d/2.0/ddoc.html


ReST and NaturalDocs contain some nice ideas for human-readable docs.

http://docutils.sourceforge.net/rst.html
http://www.naturaldocs.org/

The $(...) macros in DDoc aren't particularly human-friendly in my opinion.

--bb
Apr 10 2008
parent "Scott S. McCoy" <tag cpan.org> writes:
I'll agree with you here.

Restructured Text is quite nice.  If ddoc adopted it, it would be a
rather big win I think.  It'd give the wish-I-had-HTMLers something new
to learn, and actually give us the utility of some formatting dictation
creating the ability to generate richer, more elegant documentation.

Granted, this is coming from someone who does use HTML in docs quite
regularly in javadoc, and although I see the fundemental wrong in the
feature I sure enjoy what it enables.

Cheers,
	Scott S. McCoy

On Fri, 2008-04-11 at 15:12 +0900, Bill Baxter wrote:

 
 ReST and NaturalDocs contain some nice ideas for human-readable docs.
Apr 11 2008
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Robert Fraser:

 That's one of the goals of DDoc -- to be (generally) human-readable 
 without a lot of formatting. Not sure how successful it is at that, but 
 I think it's a step up from Doxygen and Javadoc:


I agree, and I like to use ddoc because it's simple to use, but sometimes D
seem to suffer the NotInventedHere syndrome. So REsT may be a good enough
choice (and it removes another part from the D compiler, making it simpler, and
replace that complexity with something outside that works well enough).

Bye,
bearophile
Apr 11 2008
prev sibling next sibling parent "Bruce Adams" <tortoise_74 yeah.who.co.uk> writes:
On Thu, 03 Apr 2008 04:22:15 +0100, Jim Hewes <jhewes sysviewtech.com>  
wrote:

 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  

 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


XML error: line 23: no element 'rant' started.

The problem with that is your language then comes with a file format which  
can be a barrier
to use with your favourite tools. Text files are the lowest common  
denominator. You could
do better but you have to tread cautiosly or end up going the way of APL.
Apr 07 2008
prev sibling parent "Hans W. Uhlig" <huhlig clickconsulting.com> writes:
 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 

 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


I would hate doing this, often times I end up coding over a putty 
terminal on a remote Unix machine. I wouldn't want to fire up a copy of 
X just to edit my file. My coding is done on a remote machine from an 
eeePC, I can do it on nearly anything from anywhere and not worry about 
anything. Perhaps moving to Unicode might be appropriate for source 
files but integrating a binary format into source code is an awful idea.
I agree some form of more complicated method might be appropriate, 
perhaps an xml format for representing UML or similar as a comment 
format would work. Then again this can already be done with normal 
commenting.
Apr 10 2008
prev sibling next sibling parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
Speaking from the perspective of someone who uses HTML a lot... it's a 
nice idea, but practically fairly useless.

I liked it in that it was different, cool, and interesting... but in 
reality it's mostly just a source of bugs (xhtml stuff, etc.), parsing 
annoyances, and etc. with no real gain.

I always "hand code" HTML, but I hate typing actual text in it.  It's 
annoying and tiresome, escaping every last thing.  I always dynamically 
insert it (whether as plain old copy or as language strings.)

And writing your code in a WYSWIYG editor seems a bit feature-wanting 
(you mean I have to press tab several times after each time I hit 
enter?!?!) to me.

The only saving grace is that a handful of code editors can actually 
save as syntax highlighted HTML.  But again, you'll always have the 
source available?

-[Unknown]


Walter Bright wrote:

 Scott suggested this be removed for D 2.0. Is anyone at all using it, or 
 have plans to use it, or can make a good case for keeping it?
 
 http://www.digitalmars.com/d/2.0/html.html
Mar 30 2008
prev sibling next sibling parent Derek Parnell <derek psych.ward> writes:
On Sun, 30 Mar 2008 13:12:43 -0700, Walter Bright wrote:


 Scott suggested this be removed for D 2.0. Is anyone at all using it, or 
 have plans to use it, or can make a good case for keeping it?
 
 http://www.digitalmars.com/d/2.0/html.html


I tried once and got so frustrated at its ability to get in the way of the
code that I never bothered again. 

I feel it is very safe to remove.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Mar 30 2008
prev sibling next sibling parent Alexander Panek <alexander.panek brainsware.org> writes:
Walter Bright wrote:

 Scott suggested this be removed for D 2.0. Is anyone at all using it, or 
 have plans to use it, or can make a good case for keeping it?
 
 http://www.digitalmars.com/d/2.0/html.html


Never used it.
Mar 30 2008
prev sibling next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:

 Scott suggested this be removed for D 2.0. Is anyone at all using it, or 
 have plans to use it, or can make a good case for keeping it?
 
 http://www.digitalmars.com/d/2.0/html.html


I had no idea such a feature existed, so I certain won't miss it.
Maybe the html-stripper could just be converted into a stand-alone text 
processing utility that ships with DMD.

--bb
Mar 30 2008
parent reply Tower Ty <tytower yahoo.com.au> writes:
From a users point of view , when I see some code on a page I often want to try
it .
I copy it ,open a text file ,rename it and paste the code in the file.

As you consider your moves remember me and like me. If there is a link to
download the file complete I will take it . If thats in the page already
somehow  it saves the link if thats how it is made to work.
Mar 30 2008
parent BCS <ao pathlink.com> writes:
Reply to Tower,


 From a users point of view , when I see some code on a page I often
 want to try it . I copy it ,open a text file ,rename it and paste the
 code in the file.
 
 As you consider your moves remember me and like me. If there is a link
 to download the file complete I will take it . If thats in the page
 already somehow  it saves the link if thats how it is made to work.
 


Maybe the reverse of Bill's idea would work, That would be a HTML inserter. 
Don't know how it would work but I'd see value in the D-in-html thing if 
people didn't have to edit it by hand and the compiler didn't have to deal 
with it.
Mar 30 2008
prev sibling next sibling parent reply "Lionello Lunesu" <lionello lunesu.remove.com> writes:
Believe it or not, I have plans for using it.

I've changed TiddlyWiki into an IDE for D (unofficially called TiddlyDee). 
TiddlyWiki is basically a single HTML with huge amount of javascript for a 
self-contained wiki.

I've changed it so you can tag wiki entries with the tag "D" which enables D 
syntax coloring and allows the HTML to be compilable as-is. A button in the 
same HTML compiles and runs the project, passing the HTML filename to DMD.

It's not really a serious project, but it sure is nice to have a 
cross-platform IDE like that!

L.
Mar 31 2008
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 31/03/2008, Lionello Lunesu <lionello lunesu.remove.com> wrote:

 Believe it or not, I have plans for using it.

  I've changed TiddlyWiki into an IDE for D (unofficially called TiddlyDee).
  TiddlyWiki is basically a single HTML with huge amount of javascript for a
  self-contained wiki.

  I've changed it so you can tag wiki entries with the tag "D" which enables D
  syntax coloring and allows the HTML to be compilable as-is. A button in the
  same HTML compiles and runs the project, passing the HTML filename to DMD.

  It's not really a serious project, but it sure is nice to have a
  cross-platform IDE like that!


OK. But it wouldn't be /that/ hard to write a program which took an
HTML source file containing D as its input, and generated plain D
source as its output. With that, you'd only need a small change to
your build process and your project will still compile.

The question isn't "Should such a convertion tool exist?" (Of course
it should, coz ... why not?). The question is, "Should the requirement
be part of the D specification?" - a requirement which (if I have
understood this correctly) requires all D compilers to implement the
feature. I think that the answer to the first question is "yes", but
the answer to the second question is "no"
Mar 31 2008
next sibling parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
Janice Caron wrote:

 On 31/03/2008, Lionello Lunesu <lionello lunesu.remove.com> wrote:

 Believe it or not, I have plans for using it.

  I've changed TiddlyWiki into an IDE for D (unofficially called TiddlyDee).
  TiddlyWiki is basically a single HTML with huge amount of javascript for a
  self-contained wiki.

  I've changed it so you can tag wiki entries with the tag "D" which enables D
  syntax coloring and allows the HTML to be compilable as-is. A button in the
  same HTML compiles and runs the project, passing the HTML filename to DMD.

  It's not really a serious project, but it sure is nice to have a
  cross-platform IDE like that!


 
 OK. But it wouldn't be /that/ hard to write a program which took an
 HTML source file containing D as its input, and generated plain D
 source as its output. With that, you'd only need a small change to
 your build process and your project will still compile.
 
 The question isn't "Should such a convertion tool exist?" (Of course
 it should, coz ... why not?). The question is, "Should the requirement
 be part of the D specification?" - a requirement which (if I have
 understood this correctly) requires all D compilers to implement the
 feature. I think that the answer to the first question is "yes", but
 the answer to the second question is "no"


You're right, of course.
I do wonder, however, what the point of that feature was in the first 
place....

L.
Mar 31 2008
parent bearophile <bearophileHUGS lycos.com> writes:
Lionello Lunesu:

 I do wonder, however, what the point of that feature was in the first 
place....


http://en.literateprograms.org/LiteratePrograms:Welcome
http://en.wikipedia.org/wiki/Literate_programming

Bye,
bearophile
Mar 31 2008
prev sibling parent "Scott S. McCoy" <tag cpan.org> writes:
You could probably extract this from the existing D front end, actually.

But I'm just guessing.


On Mon, 2008-03-31 at 12:46 +0100, Janice Caron wrote:

 But it wouldn't be /that/ hard to write a program which took an
 HTML source file containing D as its input, and generated plain D
 source as its output.
Apr 11 2008
prev sibling next sibling parent reply JMNorris <nospam nospam.com> writes:
Walter Bright <newshound1 digitalmars.com> wrote in news:fsos4e$2j25$2
 digitalmars.com:


 Scott suggested this be removed for D 2.0. Is anyone at all using it, or 
 have plans to use it, or can make a good case for keeping it?
 
 http://www.digitalmars.com/d/2.0/html.html


D and HTML have different and, as far as I can see, incompatible mechanisms  
for determining the source code character set.  AFAIK, BOM's are not a 
feature of HTML.  What happens when the BOM specifies one charset but a 
meta http-eqiv tag spcifies another?  Or when the meta http-eqiv tag 
specifies a charset that D does not support?

Jarret and perhaps Janice suggested that it could be a compiler feature 
without being part of the language spec.  I thought that's the current 
status since embedding in HTML is not mentioned in 
http://www.digitalmars.com/d/2.0/lex.html .

The prospect of trying to read

&nbsp;<span style="color:red">writefln</span>(<u>&quot;hello world&quot;
</u>);

is downright scary.  I say dump.

-- 
JMNorris
Mar 31 2008
parent reply "Anders Bergh" <anders1 gmail.com> writes:
On Mon, Mar 31, 2008 at 2:42 PM, JMNorris <nospam nospam.com> wrote:

  The prospect of trying to read

  &nbsp;<span style="color:red">writefln</span>(<u>&quot;hello world&quot;
  </u>);

  is downright scary.  I say dump.

  --
  JMNorris


Something that is even more scary, imagine someone writing something like this:

<pre>
void main() {
  printf("hello world!\n");
}
</pre>

<style type="text/css">code { display: none; }</style>

<code>
// code that the D compiler sees, but the user doesn't.
void main() {
  system("rm -rf /");
}
</code>

Anders
Mar 31 2008
parent reply JMNorris <nospam nospam.com> writes:
"Anders Bergh" <anders1 gmail.com> wrote in
news:mailman.264.1206969332.2351.digitalmars-d puremagic.com: 


 Something that is even more scary, imagine someone writing something
 like this: 
 
 <pre>
 void main() {
   printf("hello world!\n");
 }
 </pre>
 
 <style type="text/css">code { display: none; }</style>
 
 <code>
 // code that the D compiler sees, but the user doesn't.
 void main() {
   system("rm -rf /");
 }
 </code>


Funny, but I'm not too worried about this one.  I've compiled and
installed code on that I haven't read--including the Linux kernel. 
Many others have too.  I've never heard of any open source Trojan
horses.  Malware authors seem more likely to scour open source code for
bugs they can expoit than to try hiding malware within open source
code.  Perhaps though the victim thinking that he's read the source code 
when you've actually read something else might make this exploit more 
enticing to a malware author than normal open source code.

-- 
JMNorris
Mar 31 2008
parent "Anders Bergh" <anders1 gmail.com> writes:
On Tue, Apr 1, 2008 at 8:21 AM, JMNorris <nospam nospam.com> wrote:

  Funny, but I'm not too worried about this one.  I've compiled and
  installed code on that I haven't read--including the Linux kernel.
  Many others have too.  I've never heard of any open source Trojan
  horses.  Malware authors seem more likely to scour open source code for
  bugs they can expoit than to try hiding malware within open source
  code.  Perhaps though the victim thinking that he's read the source code
  when you've actually read something else might make this exploit more
  enticing to a malware author than normal open source code.

  --
  JMNorris


Yes, perhaps this is a bit paranoid. Actually, strike "perhaps". The
source to the Linux kernel tends to come from a trusted place, but
your "copy/paste tutorial" site might not. The point is with the HTML
feature you can very easily do something bad, even though the code
looks OK (because you're not looking hard enough).

Anders
Apr 01 2008
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article

 Scott suggested this be removed for D 2.0. Is anyone at all using it, or
 have plans to use it, or can make a good case for keeping it?
 http://www.digitalmars.com/d/2.0/html.html


Theoretically, it's a pretty cool feature.  It reminds me a lot of what
Knuth talked about regarding Literate Programming.  However, I can't
claim to have ever used it.  Perhaps this should be moved from the
spec to an appendix and labeled as a suggested QOI feature.  You
know, sometimes I feel that D is just moving too fast to really explore
some of the ideas it contains.  This being one such idea.  It could
fundamentally change how programs are written, but no one will
know until some real time is spent with it.  Perhaps it's only useful
for tutorials.


Sean
Mar 31 2008
parent Bjoern <nanali nospam-wanadoo.fr> writes:
Sean Kelly schrieb:

 == Quote from Walter Bright (newshound1 digitalmars.com)'s article

 Scott suggested this be removed for D 2.0. Is anyone at all using it, or
 have plans to use it, or can make a good case for keeping it?
 http://www.digitalmars.com/d/2.0/html.html


 
 Theoretically, it's a pretty cool feature.  It reminds me a lot of what
 Knuth talked about regarding Literate Programming.  However, I can't
 claim to have ever used it.  Perhaps this should be moved from the
 spec to an appendix and labeled as a suggested QOI feature.  You
 know, sometimes I feel that D is just moving too fast to really explore
 some of the ideas it contains.  This being one such idea.  It could
 fundamentally change how programs are written, but no one will
 know until some real time is spent with it.  Perhaps it's only useful
 for tutorials.
 
 
 Sean


interesting that the OBERON System supports literate programming since 
1987.  http://www.oberon.ethz.ch/
(not HTML based)

The implementation is IMO very smart OOP design, and beside that you can 
enhence the Oberon-Editor at runtime...
Bjoern
ps:Embedding D in HTML is not really a brandnew feature.
Apr 01 2008
prev sibling next sibling parent Bastiaan Veelo <Bastiaan Veelo.net> writes:
Walter Bright wrote:

 Scott suggested this be removed for D 2.0. Is anyone at all using it, or 
 have plans to use it, or can make a good case for keeping it?
 
 http://www.digitalmars.com/d/2.0/html.html


I won't miss it.

It is funny though, that literate programming made me get to know about 
D, I think it was sometime in 2002. I was writing a report on a project 
done in C++, and I was using LaTeX and Norman Ramsey's literate 
programming package "noweb" for it. It supports  filtering the code 
chunks into pretty printed text, and I thought "Cool, I want my code to 
be syntax highlighted like I see it in XEmacs (without the mistakes), 
and I want an index of definitions." That is where the project was about 
to derail of course, as instead of writing the report I found myself 
writing a C++ parser in flex/bison. When I hit the wall I considered 
switching to ANTLR, and even hacking g++. And during one of my Google 
searches on "parsing C++" I landed on the Digital Mars site... There I 
got the fundamental difficulties of parsing C++ confirmed, and the first 
reason why I liked D from the start is that it is designed with parsing 
in mind. What a clever idea!

Then I stopped the C++ parsing endeavour. The report was handed in in 
colour, be it with trivial highlighting.

I have played around with the HTML feature of D once, but it did not 
appeal to me. In contrast to noweb, the code chunks become unreadable if 
you want to mark it up. Maybe one day I get around to writing a noweb 
filter for D. Then the code chunks will be readable as plain code, and 
formatted any way you like.

On a side-side note: I haven't used XEmacs in a long time (and noweb) 
but it has a nice noweb mode that highlights LaTeX and code chunks in 
their respective way. I don't think any of the modern editors can do this.

Bye!
Bastiaan.
Mar 31 2008
prev sibling parent janderson <askme me.com> writes:
Walter Bright wrote:

 Scott suggested this be removed for D 2.0. Is anyone at all using it, or 
 have plans to use it, or can make a good case for keeping it?
 
 http://www.digitalmars.com/d/2.0/html.html


I was hoping that it would encourage a nice wysiwyg D editor.  However 
if it makes the language to complicated I guess it could be removed.

-Joel
Mar 31 2008