TeX directory structures

David Kellerman davek@nls.com
Fri, 7 Oct 94 13:27:11 PST


NAME:	David Kellerman
	Northlake Software
EMAIL:	kellerman@nls.com

TEX IMPLEMENTATION: Convergent TeX for VMS

This version of TeX currently supports (delete ones which don't apply):

 * only one directory for each sort of file (for example, all tfm
   files have to be in fonts/tfm)

 * a list of directories for each sort of file (for example, you can
   specify fonts/tfm/adobe and fonts/tfm/monotype)

By this time next year, this version of TeX should (don't worry, we
won't hold you to this one!) support:

 * only one directory for each sort of file

 * a list of directories for each sort of file

 * one level of subdirectory searching

 * many-level subdirectory searching

 * many-level subdirectory searching with pruning

If the TUG technical working group ask us to, we will implement:

 * only one directory for each sort of file

 * a list of directories for each sort of file

 * one level of subdirectory searching

 * many-level subdirectory searching

 * many-level subdirectory searching with pruning

Any other comments:

Please choose a solution that maps cleanly to user environments

    I think you ought to make sure whatever structure you choose
    maps cleanly onto the user interface already in place in
    each of the environments where people will be using it. 

    I think you get into trouble when you try to reinvent
    familiar portions of the user interface -- you end up
    working at cross-purposes with what users are already
    comfortable with.  Every time you educate a new user, you
    start with "this is different from what you'd expect," and
    every time the user uses the feature, they ask "now how did
    that work, it was different from what I'm used to?"

    VMS, in particular, has basically two constructions that let
    you search multiple directories: 
    Wildcards
        for entire directory names: 
            [fonts.tfm.*] matches [fonts.tfm.adobe],
                [fonts.tfm.monotype], etc.
            [fonts.*.times] matches [fonts.tfm_adobe.times],
                [fonts.tfm_monotype.times], etc.
        for parts of directory names:
            [fonts.tfm_*] matches [fonts.tfm_adobe],
                [fonts.tfm_monotype], etc.
    Ellipses
        for an arbitrary sequence of zero or more directory names:
            [fonts...times] matches [fonts.times],
                [fonts.tfm.times], etc.

    So, with VMS, there IS a "natural" notation for one-level
    subdirectory searching, and multi-level subdirectory
    searching, including pruning.  But is there a natural way of
    doing these things in all the other systems that might
    implement these features? 

Problems with cached indexes

    I hope you don't end up with a solution that requires
    caching for reasonable performance.  It seems to me that,
    unless one does a really good job of making the cache fully
    automatic and utterly reliable, you've introduced a new
    hard-to-diagnose source of problems. 

    This may be off the subject, but I do think there is a good
    argument to be made for a different sort of auxiliary index
    -- one to map font names to filenames on brain-damaged
    systems (read MS-DOS) that only support short file names.
    That would free the rest of the world from dealing with
    encrypted names. 

Please mail this to alanje@cogs.susx.ac.uk.