Re: multiple categories

[Guido Draheim]

Peter Simons schrieb:
> Guido Draheim writes:
>
>  > [...] the macro name does not carry all [...]
>
> That is why I introduced the short description, which authors can use
> in case the macro name is not expressive enough. Also, a search engine
> would find the keyword in the documentation as well.
>
>
>  > [...] the macro names have lots of recurring bits that make the
>  > table very long in kilobytes
>
> As of now, the macro index page is 18 kilobytes large, and I expect it
> to shrink once we went through the current contents. I don't think
> that the size of the HTML document is really an issue, given that most
> web sites carry megabytes worth of images, while we provide 18
> kilobytes of actual content.

indeed - kilobytes was the wrong term, it's more a matter of the
number of pages that one will scroll up and down *sigh* sorry,
got that wrong...

> Besides, putting macros into multiple categories will make the pages
> _larger_, not smaller.

would you please now go to sfnet and have a look? The frontpage
contains the main categories and it does not list any macro
twice. The per-category indexes lists only the macros in that
category plus handful extra, nothing really fat that could
eat away the intended gain. The extra macros are named under
the main section header from where they have migrated. Very
simple thing.

>  > let [the browser's full-text search] better work on an index-list
>  > that [contains] just the possible keys to search for, pre-ordered
>  > in fact to navigate quickly to it, and with an inverted-index of
>  > possible matches in the macros.
>
> Uh, don't you think that you're aiming for a bit too much? We're
> providing a bunch of Autoconf macros for download ... What you
> describe above would probably win us the Librarian's Nobel Prize. I
> don't mind making a cool site with advanced technology and all, but
> IMHO would should rather spend our time putting good _macros_ into it,
> then working on bleeding-edge presentation.

inverted index is easy. technique's a few decades old.

> I'd like to reiterate on the lessons learned from the World Wide Web:
> _Nobody_ cares about Yahoo these days, no matter how sophisticated
> their category system is. Everybody uses a search engine to find
> content. If we get a good search engine up and running, we'll have
> done more for the users than we possible could by enhancing the
> category system.

a search engine builds on top of an inverted index plus some
weighting rules. If the index is out-of-date or the weighting
rules stupid then the result will not be pleasing.

inverted index and yahoo directory is not similar.

>  > [...] the frontpage of sfnet has gotten too long to my taste [...].
>  > I do expect the same thing to happen with the gnu ac-archive in the
>  > near future. Since it is not the case _now_, it makes you not have
>  > that wish..... yet.
>
> This is obviously a matter of personal taste. I personally do never
> break pages up when they logically belong on one page -- just see
> <http://cryp.to/> for a somewhat extreme example -- and I have never
> ever received a single complaint about this practice.
>
> Let's say that 80 macros (of the 220 we have now) survive the review
> process, then this whole problem will be virtually non-existent. And
> given the rate of growth the archive had in the past few years, which
> will be considerably slower with the new policy, we won't have to
> worry about this for next two or three years either!

Prepare to be boarded. Resistance is futile. See here:
http://ac-archive.sf.net/guidod/ac_cflags_check.html
http://ac-archive.sf.net/guidod/ax_cflags_no_writable_strings.html

> I agree that putting a lot of effort into this issue is a good thing.
> But I doubt it is worthwhile.
>
>
> [...]
>  > The sfnet branch is shipping an `acinclude` copy of all the m4
>  > macros, and it is not a good idea to put them all into _one_
>  > directory.
>
> Why not?
>
> As far as I can tell, this is actually necessary for "aclocal" to be
> able to find them.

`acinclude` works differently. Partly out of the fact that there were
too many macros in that single aclocal directly - the `aclocal`
base command works on top of a few dozen files in a regular case,
stuffing a few hundred into that area makes it hardly maintainable.
Instead, subdirectories are used, and it is okay to symlink some
site-local directories as well additionally with those from the
gnu ac-archive or the extra parts of sfnet one. Each subdirectory
can be browsed with a pure cd/ls set (or mc).