on DDoc macros: a small problem
Charles Hixson
charleshixsn at earthlink.net
Wed Feb 20 11:40:55 PST 2013
On 02/20/2013 11:10 AM, H. S. Teoh wrote:
> On Wed, Feb 20, 2013 at 11:02:51AM -0800, Charles Hixson wrote:
>> On 02/20/2013 12:51 AM, Johannes Pfau wrote:
>>> Am Tue, 19 Feb 2013 16:43:09 -0800
>>> schrieb Charles Hixson<charleshixsn at earthlink.net>:
>>>
>>>> I have, towards the start of my file:
>>>>
>>>> /** Macros:
>>>> * Note = $(BR)$(BIG$(B$(GREEN Note:)))
>>>> * Todo =<br><font color=red><b>ToDo:</b> $0</font><br>
>>>> * Em = $(B$(BLUE $0))
>>>> * DoNotUse = $(B Do Not Use $0)
>>>> */
>>>>
>>>> Why do I need that DoNotUse macro to terminate the Em macro? If I
>>>> don't include it, the Em macro picks up the first line of the next
>>>> documentation comment, and includes it as a part of itself. I'm
>>>> clearly doing something wrong, but I have no idea what.
> [...]
>
> I'm not sure if I'm completely off-base here, but have you tried
> inserting a space between the macro name and its parameters? Like:
>
> Em = $(B $(BLUE $0))
>
> Does that make a difference?
>
> If not, I'd say you should file a bug in the issue tracker
> (d.puremagic.com/issues) so that people won't forget it needs to be
> fixed.
>
>
> T
>
I think you're misunderstanding the problem. If I place the macro
section after another documentation comment, then it *works*, sort of,
it just includes the following documentation comment as an extension of
the Em macro...unless I follow it with another macro definition.
I can't get a file description to print, only descriptions of individual
routines. I can't have a file author, only authors of individual
routines, variables, etc. I can't have a copyright on the file, only
copyrights on individual routines. ETC.
Most of this is just annoying. I don't really need a copyright notice
in the documentation, etc. But not having a version or a description at
the file level is a major pain. And it leads to an extremely contorted
syntax where the macros need to be defined after the first routine has
been documented.
Another annoyance is the way the comments are so verbose. I need to use
two lines instead of one to document a single parameter to a routine.
This makes things hard to follow in the code, because the code is
continually being scrolled off the screen to make room for documentation
comments. (I really need a much larger screen, but I don't have space
in my work area.) Doxygen comments are much nicer in this way.
But I don't really think these are bugs. I think they're design
decisions. Bad ones in my opinion, but I didn't design it. And I
haven't found a decent alternative if I need to handle "extern(C)" code
in my documentation.
More information about the Digitalmars-d-learn
mailing list