On Fri, 06 Aug 2010 18:54:51 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> Don wrote:
>> The reason they're the same is that the docs were originally written in html. The original conversion to ddoc was done via search and replace.
>> One of the HUGE benefits of ddoc is that it does highlighting of the D code. That instantly saved Walter a lot of time.
>> Seriously, converting it to ddoc did improve productivity.
>
> Here's what it has done, and this is real live experience because they were originally 100% html:
>
> 1. Yes, Don is right. It has improved ENORMOUSLY the productivity in those documents. I'm talking doubling or even tripling it.
>
> 2. I can comment out sections with $(COMMENT blah blah) and have them elided from the output. HTML comments remain in the output.
>
> 3. It has enabled the site to be written in correct, conforming HTML. Previously, it was a mess, and I didn't know what was wrong with it because it rendered ok anyway.
>
> 4. HTML has zero provision for conditional compilation. Want two HTML pages from the same source? Write two HTML pages. Note that the D1 and D2 docs are generated from the same source, this makes it easy to determine what's different between them.
>
> 5. It enabled me to produce a common look & feel for the whole site, which is hundreds of pages. This was just impossible before.
>
> 6. Even better, I can *change* the look and feel of the site with just editting a handful of macros.
>
> 7. I can update URLs across the site trivially, such as if bugzilla changes its URL.
>
> 8. As Don mentioned, it will automagically syntax highlight D code.
>
> 9. Grep doesn't work well with HTML tags. You really need an HTML-aware editor. Ddoc works with any editor (all you really need is a parentheses matcher).
>
> 10. HTML is a visually butt-ugly format that makes my eyes bleed pus. Very hard to read.

First, for 5 and 6, that is what CSS is for.

Second, I agree with all your other points (except for the eye bleeding thing).

But I find the tagging for just formatting (such as $(P, $(B $(TT) very hard to read and hard to diagnose.

It looks to me like writing D code like this:

mixin("int i = 1;");
mixin("i += 2;");

instead of this:

int i = 1;
i += 2;

Sure, the mixins are dynamic, but you are not using them in a dynamic way...

Wouldn't it be better to just write html when that's all your asking ddoc to do?  Or does the risk of blindness dissuade you too much?

FWIW, I work with HTML, CSS, php, and smarty templates every day.  I understand the value of dynamic content, but I don't use dynamic techniques to generate static content, that's written in good old html.

-Steve

-Steve

Hello Steven,

> Wouldn't it be better to just write html when that's all your asking
> ddoc  to do?  Or does the risk of blindness dissuade you too much?

What about the point (brought up else where) about being able to also generate *non* HTML from the same source?

OTOH, I agree that HTML as macros has it's flaws, how about if they were switched to something a bit more high level, something that indicates what it is doing not how it should be done?

"Mafi" <mafi@example.org> wrote in message news:i3j9el$5m7$1@digitalmars.com...
> Am 07.08.2010 06:39, schrieb Nick Sabalausky:
> (...)
>>
>> I use Programmer's Notepad 2 which does parenthesis-matching out-of-the-box.
>>
>>
> Hey, you are the first person I heard of that also uses PN2 :) . It isn't a full-featured IDE but it's a great editor for programming, isn't it.

There are a number of things I would definitely like to see added/improved: http://code.google.com/p/pnotepad/issues/list?can=1&q=reporter%3Ansetbtgnws

But those are generally fairly minor things, and a number of them I think are really more scintilla than PN2 (PN2 uses the scintilla text-edit control).

So yea, overall I've been very happy with it, much more than any other editor I've tried. Doesn't have the sluggishness and bloat of VS.NET and Eclipse (doesn't have all the bells and whistles of Eclipse, but I can live without bells and whistles, especially if I'm not using Java). Doesn't have the strange "10% CPU usage while idle" or long start-up time or non-MRU-based ctrl-tab system that C::B has, or C::B's insistence on always trying to open HTML in a WYSIWYG instead of text-mode. Doesn't do the weird "EOL isn't treated as EOL" behavior some other editors do. Doesn't require tons of configuration. Highlights D out-of-the-box (and *not* by pretending it's C/C++). And it does all the basics I need, like basic project support, external command-line tools, customizable cmd-line-tool output parsing for jump-to-file/line/position, keyboard commands for comment/indent/unindent, find in files, show/hide whitespace and/or EOL markers, tabs <-> spaces, doesn't try to use any weird skins, doesn't waste UI space, doesn't have "invisible-text-syndrome", etc.

Steven Schveighoffer wrote:
> Wouldn't it be better to just write html when that's all your asking ddoc to do?

As I mentioned, I've tried it that way, and ddoc makes me 2 or even 3 times more productive doing it.

On 2010-08-08 01:02, Lutger wrote:
> Walter Bright wrote:
>
>> Jeff Nowakowski wrote:
>>> On 08/07/2010 01:40 AM, Walter Bright wrote:
>>>>
>>>> What's odd about how pointlessly verbose it is, is it was designed in
>>>> the era of modems. You'd think that tightening up the syntax would be a
>>>> priority.
>>>
>>> Do you really think those<p>  tags and<a href>  tags were choking the
>>> 14.4 modems of the time? When HTML was first designed, it was a simple
>>> markup language.
>>
>> A typical HTML source file is about double the size it needs to be if HTML
>> were designed better. A lot of sites did work hard to try to shrink their HTML
>> pages so they'd load faster.
>>
>
> For example, haml with Ruby on Rails: http://haml-lang.com/ The markup is
> readable and maps very easy to html.

haml is a great language but it is converted to html so there is no space saving.


-- 
/Jacob Carlborg

Hehe, actually there's a way to disable the CTRL+Tab behavior in C::B and let Scintilla handle it the default way. Which is what I did, but then I uncovered a bug where C::B would crash if I were using CTRL+Tab while the text editor was not active. I'm still waiting for a better patch for D support in C::B, or I'll have to get off my lazy bum and configure everything manually.

On Sun, Aug 8, 2010 at 5:36 AM, Nick Sabalausky <a@a.a> wrote:

> "Mafi" <mafi@example.org> wrote in message news:i3j9el$5m7$1@digitalmars.com...
> > Am 07.08.2010 06:39, schrieb Nick Sabalausky:
> > (...)
> >>
> >> I use Programmer's Notepad 2 which does parenthesis-matching out-of-the-box.
> >>
> >>
> > Hey, you are the first person I heard of that also uses PN2 :) . It isn't a full-featured IDE but it's a great editor for programming, isn't it.
>
> There are a number of things I would definitely like to see added/improved: http://code.google.com/p/pnotepad/issues/list?can=1&q=reporter%3Ansetbtgnws
>
> But those are generally fairly minor things, and a number of them I think are really more scintilla than PN2 (PN2 uses the scintilla text-edit control).
>
> So yea, overall I've been very happy with it, much more than any other editor I've tried. Doesn't have the sluggishness and bloat of VS.NET and Eclipse (doesn't have all the bells and whistles of Eclipse, but I can live without bells and whistles, especially if I'm not using Java). Doesn't have the strange "10% CPU usage while idle" or long start-up time or non-MRU-based ctrl-tab system that C::B has, or C::B's insistence on always trying to open HTML in a WYSIWYG instead of text-mode. Doesn't do the weird "EOL isn't treated as EOL" behavior some other editors do. Doesn't require tons of configuration. Highlights D out-of-the-box (and *not* by pretending it's C/C++). And it does all the basics I need, like basic project support, external command-line tools, customizable cmd-line-tool output parsing for jump-to-file/line/position, keyboard commands for comment/indent/unindent, find in files, show/hide whitespace and/or EOL markers, tabs <-> spaces, doesn't try to use any weird skins, doesn't waste UI space, doesn't have "invisible-text-syndrome", etc.
>
>
>

On Sun, 08 Aug 2010 00:26:42 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> Steven Schveighoffer wrote:
>> Wouldn't it be better to just write html when that's all your asking ddoc to do?
>
> As I mentioned, I've tried it that way, and ddoc makes me 2 or even 3 times more productive doing it.

You're not getting what I'm saying, so I'll just stop :)

Thanks for trying.

-Steve

Steven Schveighoffer wrote:
> On Sun, 08 Aug 2010 00:26:42 -0400, Walter Bright <newshound2@digitalmars.com> wrote:
> 
>> Steven Schveighoffer wrote:
>>> Wouldn't it be better to just write html when that's all your asking ddoc to do?
>>
>> As I mentioned, I've tried it that way, and ddoc makes me 2 or even 3 times more productive doing it.
> 
> You're not getting what I'm saying, so I'll just stop :)

Sorry.

> 
> Thanks for trying.
> 
> -Steve

Sat, 07 Aug 2010 16:54:03 +0200, Jacob Carlborg wrote:

> On 2010-08-07 00:54, Walter Bright wrote:
>> Don wrote:
>>> The reason they're the same is that the docs were originally written in html. The original conversion to ddoc was done via search and replace. One of the HUGE benefits of ddoc is that it does highlighting of the D code. That instantly saved Walter a lot of time. Seriously, converting it to ddoc did improve productivity.
>>
>> Here's what it has done, and this is real live experience because they were originally 100% html:
>>
>> 1. Yes, Don is right. It has improved ENORMOUSLY the productivity in those documents. I'm talking doubling or even tripling it.
>>
>> 2. I can comment out sections with $(COMMENT blah blah) and have them elided from the output. HTML comments remain in the output.
>>
>> 3. It has enabled the site to be written in correct, conforming HTML. Previously, it was a mess, and I didn't know what was wrong with it because it rendered ok anyway.
>>
>> 4. HTML has zero provision for conditional compilation. Want two HTML pages from the same source? Write two HTML pages. Note that the D1 and D2 docs are generated from the same source, this makes it easy to determine what's different between them.
>>
>> 5. It enabled me to produce a common look & feel for the whole site, which is hundreds of pages. This was just impossible before.
>>
>> 6. Even better, I can *change* the look and feel of the site with just editting a handful of macros.
>>
>> 7. I can update URLs across the site trivially, such as if bugzilla changes its URL.
>>
>> 8. As Don mentioned, it will automagically syntax highlight D code.
>>
>> 9. Grep doesn't work well with HTML tags. You really need an HTML-aware editor. Ddoc works with any editor (all you really need is a parentheses matcher).
>>
>> 10. HTML is a visually butt-ugly format that makes my eyes bleed pus. Very hard to read.
> 
> I think for any serious HTML work you need a server side language to help you.

Comparing hand-written html to ddoc is a bit unfair. I've used several CMS and template systems. They even have good support for D. My experiences tell me that

1. ddoc has worse productivity than real document generators such as doxygen or good cms/markup/web template systems.

2. these other systems also support commenting out stuff

3. these other systems also support generating correct, conforming HTML/ XML/TeX/PDF/MAN/whatever. With ddoc you need to use some semi-official templates you need to dig from the newsgroup archives. Doxygen provides all this by default. How is that bad for productivity?

4. these other systems also support conditional compilation

5-6. these other systems also support separating the style/layout from the structure.

7. ditto (and it's better than what ddoc produces by default)

8. ditto (and it's better than what ddoc produces). ddoc doesn't extract all components of symbol signatures in a structured way.

9. ditto

10. the other systems look better than ddoc

So overall the other systems are much better and I also think I could write something 10 times better than ddoc in 2..7 days if someone would give me an untainted GPL licensed frontend that didn't look so butt ugly.

You are just becoming a parody of yourself.

Keep trying, though.

On Sat, 14 Aug 2010 15:06:04 -0500, retard <re@tard.com.invalid> wrote:

> Sat, 07 Aug 2010 16:54:03 +0200, Jacob Carlborg wrote:
>
>> On 2010-08-07 00:54, Walter Bright wrote:
>>> Don wrote:
>>>> The reason they're the same is that the docs were originally written
>>>> in html. The original conversion to ddoc was done via search and
>>>> replace. One of the HUGE benefits of ddoc is that it does highlighting
>>>> of the D code. That instantly saved Walter a lot of time. Seriously,
>>>> converting it to ddoc did improve productivity.
>>>
>>> Here's what it has done, and this is real live experience because they
>>> were originally 100% html:
>>>
>>> 1. Yes, Don is right. It has improved ENORMOUSLY the productivity in
>>> those documents. I'm talking doubling or even tripling it.
>>>
>>> 2. I can comment out sections with $(COMMENT blah blah) and have them
>>> elided from the output. HTML comments remain in the output.
>>>
>>> 3. It has enabled the site to be written in correct, conforming HTML.
>>> Previously, it was a mess, and I didn't know what was wrong with it
>>> because it rendered ok anyway.
>>>
>>> 4. HTML has zero provision for conditional compilation. Want two HTML
>>> pages from the same source? Write two HTML pages. Note that the D1 and
>>> D2 docs are generated from the same source, this makes it easy to
>>> determine what's different between them.
>>>
>>> 5. It enabled me to produce a common look & feel for the whole site,
>>> which is hundreds of pages. This was just impossible before.
>>>
>>> 6. Even better, I can *change* the look and feel of the site with just
>>> editting a handful of macros.
>>>
>>> 7. I can update URLs across the site trivially, such as if bugzilla
>>> changes its URL.
>>>
>>> 8. As Don mentioned, it will automagically syntax highlight D code.
>>>
>>> 9. Grep doesn't work well with HTML tags. You really need an HTML-aware
>>> editor. Ddoc works with any editor (all you really need is a
>>> parentheses matcher).
>>>
>>> 10. HTML is a visually butt-ugly format that makes my eyes bleed pus.
>>> Very hard to read.
>>
>> I think for any serious HTML work you need a server side language to
>> help you.
>
> Comparing hand-written html to ddoc is a bit unfair. I've used several
> CMS and template systems. They even have good support for D. My
> experiences tell me that
>
> 1. ddoc has worse productivity than real document generators such as
> doxygen or good cms/markup/web template systems.
>
> 2. these other systems also support commenting out stuff
>
> 3. these other systems also support generating correct, conforming HTML/
> XML/TeX/PDF/MAN/whatever. With ddoc you need to use some semi-official
> templates you need to dig from the newsgroup archives. Doxygen provides
> all this by default. How is that bad for productivity?
>
> 4. these other systems also support conditional compilation
>
> 5-6. these other systems also support separating the style/layout from
> the structure.
>
> 7. ditto (and it's better than what ddoc produces by default)
>
> 8. ditto (and it's better than what ddoc produces). ddoc doesn't extract
> all components of symbol signatures in a structured way.
>
> 9. ditto
>
> 10. the other systems look better than ddoc
>
> So overall the other systems are much better and I also think I could
> write something 10 times better than ddoc in 2..7 days if someone would
> give me an untainted GPL licensed frontend that didn't look so butt ugly.


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/