GNU Texinfo 5.0 Released 173
Four years after the last release, version 5.0 of Texinfo, the GNU documentation language, has been released. The primary highlight is a new implementation of makeinfo info in Perl rather than C. Although slower, the new version offers several advantages: cleaner code using a structured representation of the input document, Unicode support, and saner support for multiple output backends. There are over a dozen other improvements including better formatting of URLs, improved cross-manual references, and a program to convert Perl POD documentation to Texinfo.
Speed. (Score:4, Interesting)
I love how a language that was "fast enough" in the '90s is now suddenly "too slow" in 2013.
What's with the "I need all my code hyper-optimized" crowd on /. these days? We running a Gentoo help forum I didn't notice?
Re:Perl POD is a good man input format (Score:4, Interesting)
It's very handy for generating both nroff man pages and their HTML counterparts from the same input text. Being extremely simple, it raises no barrier to writing man-page type documentation.
Neither does nroff -man. If you're in a position where you'd want a man page, a percieved complexity in writing one in nroff is no excuse. Read man(7), groff_man(7) and groff_char(7), and look at some example man pages for inspiration.
Also, if the cvs(1) man page of CVS 1.12.13 is a typical example of what Texinfo generates, I strongly recommend against using it for this. It's ugly and hard to read; doesn't really look like a man page at all.
Re:Do not want (Score:2, Interesting)
Both texinfo and man have their place. texinfo is good for learning the deep details of a product. man pages are good for quick "what was that option for doing X again?" checks.
The attitude of the FSF towards man pages is, to put it politely, stupid. And counterproductive. Damnit, the response to a bug report saying "the man page is out of date/inaccurate/incorrect" should be to fix the damn man page, not to remove it!
Don't get me wrong, there are times when the texinfo documentation is incredibly useful, and I like having it available ... but I like having quick references as well!
Re:Oblig oblig XKCD (Score:5, Interesting)
What I find interesting about this Perl rewrite is that Guile, ostensibly the official scripting language of GNU, has had excellent structured texinfo support [gnu.org] for years now. It uses stexi which has the same structure as sxml, so you gain access to all of the really great Scheme XML processing tools, including SXSLT which is basically ideal for spitting out arbitrary formats.
Re:Things you don't hear every day (Score:5, Interesting)
"Nobody could understand the source code anymore without massive doses of caffeine... ao we decided to rewrite the whole thing in Perl."
Oblig xkcd [xkcd.org]
Obligatory Rebuttal xkcd [xkcd.com]
This is interesting for two reasons:
0. It was Perl's built in features, such as regex, system calls, and ability to be terse enough to enter a solution on a single swinging pass that make it an obvious choice -- It was made for this type of job.
1. I'm confident that if we have not already, we will soon reach a point where entire discussions can be composed of no text other than xkcd links. [xkcd.com]
Just an End User (Score:4, Interesting)
Google + Forums is what real people rely on.
Re:Will an end user notice this speed degradation? (Score:3, Interesting)
Texinfo produces very nice paper manuals effortlessly. With Docbook one has to dive into XSL-FO unpleasantness.
Re:Perl hater (Score:5, Interesting)
I think that calling C "portable assembly" is really a bit untrue. One of the core features of most any machine language is that flags are part of the result of many computing operations. Yet C completely removes access to it.
Suppose you have a code that adds two things, then jumps on overflow. On most machines that's two instructions if the operands have the right size. You look at it, and the intent is obvious: we add, then jump on overflow.
Things are seriously wrong (IMHO) if a higher level language completely obfuscates this and requires code where it's not obvious at all what you mean! Heck, what's worse, each compiler likely requires slightly different code so that the meaning is extracted by the optimizer and the correct assembly output is produced without paying both code size and performance penalties! In C, the best you can do on a good compiler is to have an inlineable function that returns the numerical part of the result, uses comparisons to "recreate" the detection of overflow, and returns the overflow condition in a char* out-parameter. If the optimizer is good, it'll recognize that the out parameter accesses an automatic variable in the caller, and that your comparison is just checking for overflow. This code, while portable C, will perform horribly as soon as you compile it without state-of-the-art optimization capabilities. I'd think that means that if your compiler wasn't released in the last year or two, and isn't a mainstream decently optimizing one (like gcc, llvm, visual studio), you're out of luck. On many platforms a saturating increment/decrement is also two or three assembly instructions at most, without jumps -- but good luck getting a compiler to actually emit such code.
I think that providing no way to access the flags part of arithmetic operation results is one of the biggest oversights in C. I'd think that every platform C runs on provides such flags.