Re: Is any future development needed on 'dir' files?

[Alfred M. Szmidt]

   > >  - Monitor and improve the dir categories in existing manuals,
   > >    following the Free Software Directory categories.  Much mail to
   > >    developers has already been sent, what's needed now is to check new
   > >    releases and make sure they are using the right categories.
   > >    See the util/dir-example in the Texinfo distribution for our current
   > >    recommended categories.
   > >    For background, see the thread (which discusses a lot of other
   > >    issues too) at
   > >    http://lists.gnu.org/archive/html/emacs-devel/2002-10/msg00011.html
   > >    especially
   > >      http://lists.gnu.org/archive/html/emacs-devel/2002-10/msg00090.html
   > >      http://lists.gnu.org/archive/html/emacs-devel/2002-10/msg00137.html
   > 
   > 
   > (As you can see, the messages referenced are from 2002.)
   > 
   > I personally always found the dir file a disorganised mess.  I doubt there
   > is much hope now for getting any more consistent categories than there
   > already are.
   > 
   > My feeling is that we should just give up on this.  The dir file works well
   > enough for running info from the command linen but it's not something you
   > want to look at very much, except when browsing idly to see what 
documentation
   > you have.

I curate my own dir file carefully, and I think some GNU/Linux systems
do so as well.  The one I'm looking at, some Gentoo GNU/Linux system,
seems to have a fairly useful one.  Do you have a example of a messy
dir file?

   This TODO entry seems to me to be still relevant.  But first it seems
   to me that the categories in util/dir-example do not match the categories
   in https://directory.fsf.org/wiki/Category/All.

Is that a good idea that they should match? The two have different
purposes, I think.

   And then when the categories are updated, someone needs to propose
   patches to change manuals as manual categories are still all over the
   place...

That is where the hard work is :-)