Re: installing new packages under mactex and texshop

Robin Fairbairns <rf10@xxxxxxxxxxxx> wrote:

real-address-in-sig@xxxxxxxxxxxxxxx (Rowland McDonnell) writes:
Juergen Fenn <jfenn@xxxxxxx> wrote:
[snip]

However there *are* docs that have a completely different name than the
packages they describe. This is why I think in order to make texdoc work
more efficiently package authors should be required to provide manuals
that bear the same name as the packages they provide. This would be
quite helpful to most users.

I think it would be a much better idea to re-work the TDS, so that code
and documentation were not stored in separate places.

What I'm thinking is that it'd be more useful to arrange things more
like this sort of thing:

<blah>/texmf.tetex/tex/latex/<packagename>/doc/
<blah>/texmf.tetex/tex/latex/<packagename>/code/
<blah>/texmf.tetex/tex/latex/<packagename>/source/

Or similar (the code directory in the above example needs to be replaced
with multiple directories at that level to meet the needs of TeX
systems, I reckon), so that flexible arrangements for documentation can
be provided without the user being lost because where the documentation
is kept is obvious.

(And that strikes me as a slightly less 1970s approach than the one in
use at the moment - I wish I knew what made it a good idea to split up
related data into different parts of the directory tree. As far as TDS
goes, my main question is `But why?')

the present structure allows the library to trim the search very near
to its root, since it knows what sort of object it's looking for.
your suggestion would have it distinguishing leaf directories for
every package on the tree.

Righto - but why not? I can see one advantage of the TDS method now -
but why not make the machinery work harder? Modern PCs certainly have
the power to do the job required without much delay and I can't help
feeling it'd make installing and maintaining things easier.

Well, it does for me - it's how I did it with OzTeX...

How to get this working with texdoc?

texdoc is made simpler by your proposed layout.

Oh! Righto.

however,
documentation is browsed on a human timescale,

Yeah, but it's sometimes damned hard to track down - myself, I find it
easier if `all the stuff to do with one package' is all in one place.
Installing TeX stuff and managing the TeX installation is easier too if
everything's in one place.

And yes I know that there is automation that's supposed to sort things
out - but my experience of that sort of thing is that it's fine until it
breaks, whereupon it makes a horribly nasty mess. So I eschew that sort
of automation and do it by hand.

whereas files for
inclusion in a document are located on the sub-second timescales of
document compilation -- if we're going to optimise anything, we should
concentrate on finding files for compilation.

Hmm. Good point.

But since the extra directory leaves that my proposal adds are right at
the bottom of the directory tree, surely they'd not slow down
compilation times to speak of? That is, if `code' is being looked for
in a tree structured like this:

<blah>/texmf.tetex/tex/latex/<packagename>/doc/
<blah>/texmf.tetex/tex/latex/<packagename>/code/
<blah>/texmf.tetex/tex/latex/<packagename>/source/

then `that which is trying to find the file' just dives straight into
<blah>/texmf.tetex/tex/latex/<packagename>/code/.

How is that significantly slower than going to
<blah>/texmf.tetex/tex/latex/<packagename>?

Point is, if you're searching for stuff only in the `code' subdirectory,
then you're not having to search more places than before, are you?

I dunno - I'm thinking of these index files that exist for speeding up
searches - surely with that kind of help and modern computers, search
times are going to be knocked down to sub microsecond these days? Which
is not necessarily a trivial delay - but surely it can't matter in the
case of then having to go away and read a file off disc?

(FWIW, this business of putting `all the stuff for one thing in one
place, with code in *that* sub-dir tree, documentation off in another,
and so on' is what has been implemented in the MacOS for normal
applications. If you happen to visit a Mac, right-click on an
application icon, `show package contents', and you'll see it all there.
Some apps aren't packages; most are. I'm told that Acorn implemented a
very similar scheme many years earlier in RISCOS.)

Go on, tell me what I've got wrong. ;-)

Rowland.

--
Remove the animal for email address: rowland.mcdonnell@xxxxxxxxxxxxxxx
Sorry - the spam got to me
http://www.mag-uk.org http://www.bmf.co.uk
UK biker? Join MAG and the BMF and stop the Eurocrats banning biking
.

Relevant Pages

  • Re: Finding installed package files
    ... > you appear to want is a file that lists executables and documentation. ... contains links to the most important information about the installation. ... > doubt others could finesse the command. ... I do understand that rpm has many options that tell me about a package. ...
    (alt.os.linux.redhat)
  • Re: debian how-to
    ... today I wanted to read up on git hook scripts. ... which tells me that git is in the "git-core" package. ... Perhaps it should be policy that if the documentation isn't in the usual ... easily access all the documentation related to a command; PDF viewers ...
    (Debian-User)
  • Re: debian how-to
    ... today I wanted to read up on git hook scripts. ... because there is no "git" package. ... So I check the source package for git-core to see if the docs got ... I think the biggest problem is that documentation is organized by ...
    (Debian-User)
  • Re: Several beginners questions
    ... manual or documentation using the wrapfig package but found none. ... That is, a full latex file that compiles, that would not show the problem anymore if you removed any line. ... The \graphicspath command may be helpful to save you some tedious typing, if you store your images in a special directory. ...
    (comp.text.tex)
  • Re: Javadoc question re Eclipse
    ... The documentation seems to be saying that I should put this file in my source tree under the package being documented. ... I tried creating a Class named package-info in Package Explorer within the ... Each package can have its own package-level doc comment source file that The Javadoc tool will merge into the documentation that it produces. ...
    (comp.lang.java.programmer)