re: multiple categories / Re: macro: guidod/patch_libtool_on_darwin_zsh_overquoting.m4

[Guido Draheim]

Peter Simons schrieb:
> Guido Draheim writes:
>
>
>  > Perhaps this is a good occasion to remind of the adoption of a
>  > @category annotation in the non-xml submission format that could
>  > list (a) multiple categorizations 
>
> Are we sure that we _really_ want to have macros sorted into multiple
> categories? Currently, the XML format does not permit this either, and
> I am not yet convinced that this would be a good idea. Allowing
> multiple categories would mean that the user would have to specify the
> category in the submission text (possibly several of them) and I can
> guarantee that half of all submission will have them spelled wrong.
>
>
>  > and (b) status information as `obsolete` or `experimental` markers.
>
> IMHO "obsolete" is a category as well. If a macro is obsolete, it is
> moved from say "cxx_support" to "obsolete" and that's it. As for
> "experimental": Should we include experimental macros (whatever that
> is :->) in the archive at all? I thought that we were moving in bold
> steps towards the goal of having _reliable_ macros in the archive?
>
> Anyway, we could simply keep macros in the "candidate" category for an
> more or less unlimited time, until the author (and the reviewers) are
> sure that it should be sorted into the main archive.

Hmmm, let's see if I can get to the point.

(a) I do think that pretty soon the autoconf macro archive will be
    filled with lots and lots of specific macros. It is not good to
    have them presented on a single page and to expect people to
    scroll the screen and to read _all_ names and check if they
    apply to his problem.

    Therefore, I do expect that people will look into just one or
    two category areas - those two that they will guess that the
    problem applies to. It does not matter whether these categories
    are just part of a single page (skipping over the other ones
    that are thought to not-apply) or presented on different index
    pages (like there is an example of that to be seen at the
    http://ac-archive.sf.net (originally for other reasons: to cut
    off the user macros from the welcome page)).

    Therefore, to make it easier to find a good macro, it would be
    good to see it reference it all categories that the archive
    maintainers thinks it is good and would be right on topic. It
    might not be btw a pressing thing right now, it was just my
    feeling at the sfnet archive where the problem of too-much
    macros might also stem from the user macros.

(b) I do respect the idea of a `firstclass category` that a
    macro would be listed on the usual overview page. And
    `obsolete` would rule out most others, that's sure, just
    like other category marks would overrule.

    It would be just needed to have `additional categories`
    around. It would be fair to present macros differently
    on topic-pages when they have migrated through some
    additional-category mark. For example, an obsoleted
    macro might only exist in the main index page in the
    section `obsoleted` but an index page about `cxx`
    could still list it but with an extra visual marker
    saying `obsoleted`  - personally I'd list firshand macros
    of that category at the top and the others beneath a ruler:

    PAGE CXX Macros:
       ac_cxx_a...
       ac_cxx_b...

    Installed                    dnl imported from that cat
       ax_find_cxx2002_compiler

    Obsoleted                    dnl i.e. moved out of the way
       ac_cxx_c

(c) as for the traditional submission format, just say what
    the `firsthand catogory` happens to be - I'd suggest
    that the last item on a @category spec counts (i.e.
    chop off everything up to the last comma)

    @category Installed Packages, obsoleted

    reason: that makes `diff`s more readable, since state
            markers are appended, and re-categorizing will
            be able through appending as well (e.g. when a
            new category is introduced

    address@hidden Installed Packages
    address@hidden Installed Packages, Perl Packages

-- cheers, guido