RE: Info tutorial is out of date

["Drew Adams" <drew.adams@oracle.com>]

    >     > Of course, it must tell people how to use the
    >     > standalone Info reader
    >
    >     Only the bare basics, because the more advanced features of the
    >     stand-alone Info reader are documented in a separate manual, which
    >     describes the stand-alone reader, and it alone.
    >
    > If there is a separate standalone-reader manual, then stuff
    > that is specific
    > to the standalone reader should go in that manual.

    See my other mail for the reasons why this would be not a good idea.

I read your other emails (unless there is yet another somewhere), and I
didn't see any reasons for this. Please point them out. I saw some
hand-waving about bootstrapping, but I saw no "reasons why this would be not
a good idea."

    Isn't the fact that you didn't even know about that other manual's
    existence tells volumes of why we shouldn't leave out stuff related to
    its basics from the beginners' Info manual?

No, I don't see the relation between my ignorance of the standalone-reader
manual and "why we shouldn't leave out stuff..." What's the connection? What
volumes does it tell? Can you be specific? You seem to be making an argument
to Authority and to hard-to-understand Complexity, but no specific obstacle
has been identified yet, AFAICT.

On the one hand, you call for concrete patches now ("put up or shut up", so
to speak), but on the other hand, your reasons given for your point of view
are nebulous.

    >     > Emacs Info is too close to the standalone Info to justify two
    >     > separate manuals, especially since many people may want
    >     > to learn how
    >     > to use both readers and we should not force them to
    >     > read two manuals
    >     > most of whose contents just duplicate each other.
    >
    >     100% agreement.
    >
    > But you just acknowledged that there are already two manuals.

    Please at least read the other manual before you argue about the
    duplication issue.  They are two different manuals--different in
    style, in preferences, and in target audience.

You should be able to characterize the difference for those of us on the
list. If there is a standalone-reader manual, then why not put stuff
specific to only the standalone reader in it (regardless of whether it is
advanced or not)? What's the obstacle to doing that? Why wouldn't that be
appropriate?

    >     Would someone who thinks they know how to make the Info
    >     manual less
    >     ``out of date'' please submit their proposed changes, so
    >     we could make
    >     this discussion more practical?
    >
    > I personally cannot contribute patches (they would not be
    > accepted, because
    > I cannot get papers from my employer).

    Well, then someone else should, or else this discussion is a waste of
    time.

Agreed, but design first, code second.

    > In any case, starting with patches would be premature. Let us agree
    > on what to present and how, before getting into the exact text.

    In my experience, people can argue forever about theoretical issues,
    then quickly come to an agreement once a practical suggestion is put
    on the table.

We all have experience of that, and also of headlong thrust into the wrong
implementation, without having discussed things and thought them through.
Pitfalls both ways. No sense arguing in that abstract way - please be
specific.

And, if patches do arrive, I'm not saying they shouldn't be discussed.

Anyway, I'm not convinced that we are arguing forever about abstractions.
AFAICT, even some (all?) of those adamant anti-mousers have said they agree
with most of my suggestions for the tutorial. If we can ever get past the
keyboard/mouse thing, then I think some progress might be made.

In the interest of advancing, we could even agree to table the question of
presenting `n', `p', etc., and come back to it later, after making some
headway improving Info along lines we might agree to. It's really not the
most important suggestion I made. You guys are tough to reason with, so I
give up on that argument, for now. Fuggeddabbouddit.