* On Sunday 2005-11-13 at 18:35:04 +0000, Julian Foad wrote: > I'm getting very annoyed by the mis-match between the man page and the info > document. I and Debian and others don't want to lose the man page, and > GNU/FSF don't want to lose the "info" document. (I could probably grow to > like the "info" format if the basic GNU "info" viewer program wasn't so > primitive and clunky.
TeXinfo is nice, because of the TeX and dvi side of things. Also because it's a real book. I do wish TeX (just like info) was more modern with regards to treating U+0027 and U+0060 as in the current (for a long time really) incarnation of ASCII, not as oriented quotes, when in verbatim monospaced text. The info format has always kinda sucked. > It even displays "man" pages (when no "info" exists) > WORSE than the standard "man" viewer does.) This is just my opinion, but the GNU Project should have done the opposite of this a long time ago, even before the advent of Linux distros. There should have been a GNU man package early on (separate from either GNU groff, GNU Emacs, standalone GNU info, or texinfo.tex), targeted at all the people who instinctively invoke "man". Nearly nobody ever got used to first typing "info"; typing "man" is the single thing that most _users_, who are not necessarily *roff coders, are attached to. This "man" should have had the native and transparent ability to read info files. Its default output would have had the typical man-output look and would have been fed to $PAGER. TeXinfo (and the info format) would have evolved with a minimal-use @ifman (or @manindex) if needed, just like @ifinfo and @iftex, mostly to document where to find a man page's traditional sections. Of course, this "man" could also have invoked nroff as well (not necessarily GNU's), just like any other "man". Then, there would never have been an incentive to develop the current man package that is commonly found on Linux distros. Maybe the standalone "info" should just have been "man --real-book --full-screen" or something. > We need one of those systems that can generate both from the same source. > Any realistic ideas? There must be some in fairly widespread use. I agree. Let's look around for tools. We may need to merge the "grep Programs" sections under "Invoking grep", which is special, but maintenance would just be more efficient.
