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