public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: Florian Weimer <fw@deneb.enyo.de> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, Subject: Re: ada/5907: The Ada front end lacks a proper manual Date: Sun, 10 Mar 2002 06:16:00 -0000 [thread overview] Message-ID: <20020310141603.480.qmail@sources.redhat.com> (raw) The following reply was made to PR ada/5907; it has been noted by GNATS. From: Florian Weimer <fw@deneb.enyo.de> To: "Joseph S. Myers" <jsm28@cam.ac.uk> Cc: <gcc-gnats@gcc.gnu.org>, <gcc-bugs@gcc.gnu.org>, <brosgol@gnat.com> Subject: Re: ada/5907: The Ada front end lacks a proper manual Date: Sun, 10 Mar 2002 15:14:48 +0100 "Joseph S. Myers" <jsm28@cam.ac.uk> writes: > On Sun, 10 Mar 2002, Florian Weimer wrote: > >> The VMS version requires substantial postprocessing (words are >> replaced globally, file names are rewritten). It is not possible to >> express this in Texinfo. > > Why not? If the standard manual needs the word "foo", where the VMS > manual needs "bar", why shouldn't a macro @foo{} (with different > definitions in the two cases) work? We would need a couple of hundered macros, I think. For example, the preprocessing rewrites all strings like "hello.adb" to "HELLO.ADB", "hello.o" to "HELLO.OBJ", and so on. If you had to write "@helloadb{}" and "@helloo{}", reading the sources would become rather difficult. > I don't think however the VMS way of building the manual would be of > relevance to the FSF sources - I think having just one version, covering > all systems, is generally preferred for GNU manuals. (If it were done > simply by a VMS Texinfo conditional, it might still make sense not to > define that conditional when building the GNU manual on VMS.) Of course, the preprocessed manual could be committed to the CVS. But I doubt that this is a reasonable approach. >> bit clumsy, and the TeX implementation of Texinfo doesn't handle >> extensive use of conditional processing and macros very well. On the > > What are the problems? Macro expansion in index entries causes problems, and so do some kind of conditionals (but these problems are more related to makeinfo, IIRC).
next reply other threads:[~2002-03-10 14:16 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2002-03-10 6:16 Florian Weimer [this message] -- strict thread matches above, loose matches on Subject: below -- 2002-10-06 2:26 Joseph S. Myers 2002-10-05 16:38 bosch 2002-03-10 11:36 Florian Weimer 2002-03-10 11:06 Joseph S. Myers 2002-03-10 3:56 Joseph S. Myers 2002-03-10 3:36 Florian Weimer 2002-03-10 3:06 Joseph S. Myers 2002-03-10 2:06 fw
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 * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20020310141603.480.qmail@sources.redhat.com \ --to=fw@deneb.enyo.de \ --cc=gcc-prs@gcc.gnu.org \ --cc=nobody@gcc.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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).