Re: macro obsoletion

[Guido Draheim]

Peter Simons wrote:
> Guido Draheim writes:
> 
>  > The `acinclude` tool is currently grepping macros for
>  > /dnl obsoleted[: ]/ lines [...].
> 
> Out of curiosity: Why did you stray from the established
> @keyword format here?

I did usually add the obsoleted warnings at the start of
of the documentation text while adding additional categories
at the low end - however we did originally want the
obsolete mark as a category attribute. Thinking up yet
another @keyword was not on my mind at that time, I guess.
And so, there is no deeper meaning here... which is also
the reason that I am open to any other means to handle it.

> 
> 
>  > I do already have a mechanism in place that serves the
>  > purpose but it can adapted easily if the syntax does
>  > change.
> 
> The alternatives we have so far are:
> 
>  (1) dnl @category obsolete
> 
>  (2) dnl @category obsolete [reason]
> 
>  (3) dnl @obsolete [reason]
> 
>  (4) dnl obsoleted: [reason]
> 
> What do the others guys think? Any opinions would be greatly
> appreciated.
> 
(1) that was the original plan
(2) breaks with earlier microsyntax of @category
    where a category name can indeed contain spaces but
    that does not break the name compound. If at all
    then it might better be @category obsolete: [hint]
(3) That is my favourite - btw I have better experiences
    with the paste tense "obsoleted" since the hint does
    fit in better in english. The acinclude tool does a
    real "grep" that keeps the "obsoleted" mark intact.
    With that knowledge everybody can see the line length
    of the obsoletion warning right there in the ac-macro
(4) Just heritage - the only advantage here: it is ensured
    to pop up in the macro documentation in the
    presentation stuff (remember I was putting it usually
    as the first line in the documentation block).

cheers,
-- guido                                  http://google.de/search?q=guidod
GCS/E/S/P C++/++++$ ULHS L++w- N++@ s+:a d(+-) r+@>+++ y++ 5++X- (geekcode)