unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Luc Teirlinck <teirllm@dms.auburn.edu>
Cc: karl@gnu.org
Subject: tramp.texi
Date: Sat, 14 Jun 2003 22:49:10 -0500 (CDT)	[thread overview]
Message-ID: <200306150349.h5F3nAl07357@eel.dms.auburn.edu> (raw)

I do not know whether the following concerns bugs in tramp.texi, in
Emacs, or in makeinfo, although I believe the two latter.  Anyway, Kai
reads Emacs devel and I included a CC to Karl.

I reported on this problem before, but I do not believe it has been
fixed.  What is new is that I now know how to deal at least with the
symptoms.

Description of the symptom:

In standalone Info (info (GNU texinfo) 4.5) do m tramp:

Result:

Cannot find node `Top'.

In Emacs we do C-h i m tramp

No problem here.  But now we do: m Overview

Result:

byte-code: No such anchor in tag table or node in tag table or file:
Overview

Now what is going on?

Tramp contains:

@c Entries for @command{install-info} to use
@dircategory Emacs
@direntry
* TRAMP: (tramp).                Transparent Remote Access, Multiple
Protocol
                                 Emacs remote file access via rsh and
rcp.
@end direntry

Perfectly correct, but apparently appears too soon.

If we kill that code and paste it later, just in front of:

@tex

@titlepage
@title @tramp{} version @trampver{} User Manual

then both the standalone and Emacs Info are suddenly perfectly happy with
tramp.texi

At first view, it seems that this was a bug in tramp.texi and we fixed
it.

I do not believe so, although making that small change will indeed
make the Tramp documentation work perfectly. I believe that there is
no bug in tramp.texi at all, but a bug in makeinfo (or in its
documentation) and a bug in texinfo-mode in Emacs.

First of all the main bug:

>From (texinfo)Installing Dir Entries:

    Always use the `@direntry' and `@dircategory' commands near the
    beginning of the Texinfo input, before the first `@node' command.  If
    you use them later on in the input, `install-info' will not notice
    them.

This warns about putting it too _late_, but tramp.texi took this
warning a little bit too seriously and put it too _early_.  But the
documentation does not mention anything about too _early_.  This is
either a bug in makeinfo or a bug in the documentation.  One can not
blame authors for taking what they are told seriously.  (I am not the
author by the way.)

While actually trying to solve the problem I ran into some auxiliary
problems, which I believe are a bug in Emacs' texinfo-mode.

What I did in Emacs was, I copied the file tramp.texi to ~/info and
ran C-u C-s C-u m on it. Then I did C-x C-s and C-c C-m C-b.  Result:

    /home/teirllm/info/tramp.texi:133: Reached eof before matching @end
    ifset.
    /home/teirllm/info/tramp.texi:126: No matching `@end menu'.
    /home/teirllm/info/tramp.texi:80: Next reference to nonexistent node
    `Overview'.
    /home/teirllm/info/tramp.texi:132: Menu reference to nonexistent node
    `History'.
    /home/teirllm/info/tramp.texi:131: Menu reference to nonexistent node
    `Obtaining @sc{tramp}'.
    /home/teirllm/info/tramp.texi:127: Menu reference to nonexistent node
    `Overview'.
    makeinfo: Removing output file `../info/tramp' due to errors; use
    --force to preserve.

    Compilation exited abnormally with code 2 at Sat Jun 14 21:10:04

This occurs with or without prior application of the "fix" described
above.  The problem is that before C-u C-s C-u m, the @end if and @end
menu were there, but C-u C-s C-u m erased them.  I believe that this
is  a bug in Emacs' texinfo-mode.  Indeed M-! makeinfo --fill-column=70
worked perfectly (after switching the above code around, as
described). 

Sincerely,

Luc.

             reply	other threads:[~2003-06-15  3:49 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-15  3:49 Luc Teirlinck [this message]
2003-06-15  4:14 ` tramp.texi Luc Teirlinck
2003-06-15  5:43   ` tramp.texi Luc Teirlinck
2003-06-15 18:53     ` tramp.texi Luc Teirlinck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200306150349.h5F3nAl07357@eel.dms.auburn.edu \
    --to=teirllm@dms.auburn.edu \
    --cc=karl@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).