GNU Texinfo 5.0 Released

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.

Comments

Things you don't hear every day

[Anonymous Coward]

"Nobody could understand the source code anymore without massive doses of caffeine... ao we decided to rewrite the whole thing in Perl."

Re:Things you don't hear every day

[one eyed kangaroo]

A witty response, but really this is getting a bit tired.

I suppose people are free to keep reading the same old, self-reinforcing sources that insist that Perl is somehow a language of the past. And if they read enough of these cliches, the anti-Perl FUD may seem to be accurate, but as any developer who spends time wrestling with real-world problems in modern Perl will attest, the so-called modern Perl ecosystem is, (just like the modern Python or PHP ecosystems), a fabulous place to work in.

I work in all three.

Re:Things you don't hear every day

[VortexCortex]

"Nobody could understand the source code anymore without massive doses of caffeine... ao we decided to rewrite the whole thing in Perl."

Oblig xkcd

Obligatory Rebuttal xkcd

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.

man texinfo

[Anonymous Coward]

Can't be much use, it doesn't have a man page.

Re:Will an end user notice this speed degradation?

[larry bagina]

how often do you run makeinfo? Probably never directly. And only indirectly if you're compiling and installing a GNU package from source (I mean, who else even uses it? )-- in which case configure checks and compilation times are the bottleneck, not makeinfo

Default to HTML yet?

[Anonymous Coward]

I haven't used TexInfo for years, but what I remember most was the absolutely abysmal standalone "info" reader. That thing was the biggest piece of shit I've ever seen in any program. Hopefully they've abandoned the crappy "info" format and all of the shitty standalone readers to view info documents, and just use HTML by default now.

Re:Default to HTML yet?

[Waffle Iron]

have you seen the HTML that gets generated from TeXInfo?

Yes. It's usually broken up into a massive hierarchy with a couple of sentences per page. You'll get cramps clicking on the navigation links while searching for the particular thing you need to find like a needle in a haystack.

Plain old man pages (especially when nicely rendered in KDE's Konqueror web browser by typing "#program-name" into the URL box) are almost invariably superior to the corresponding Texinfo docs converted to html.

Do not want

[GlobalEcho]

Allow me to initiate the inevitable hatefest:

Every time I run man and get a pointer to texinfo, I want to beat my head on the keyboard. I do not have the time, once again, to look up those obscure keyboard commands so that I may navigate laboriously through the documentation. It's time to interrupt my command-line workflow, go to the nearest GUI and run a web search for the nearest HTML manual.

Re:Do not want

[sombragris]

Try pinfo. From the description:

Pinfo is an info file viewer. It was created when the author, Przemek Borys, was very depressed trying to read gtk info entries using the standard tools.

Pinfo is similar in use to lynx. It has similar key movements, and gives similar intuition. You just move across info nodes, and select links, follow them... Well, you know how it is when you view html with lynx. :) It supports as many colors as it could.

Believe me, it's a lifesaver for reading info pages.

Re:Do not want

[swillden]

I do not have the time, once again, to look up those obscure keyboard commands so that I may navigate laboriously through the documentation.

What obscure keyboard commands? They're just the keybindings for the help system of the One True Editor. If you are using something inferior and have therefore memorized some truly obscure keyboard commands instead, how is that their fault?

Re:Do not want

[dbIII]

It was even worse when you type "man foo", get a message telling you man is evil and to use info, then the info gives you nothing but a placeholder. The gnome stuff was full of that (gconf stuff especially) before they decided to not even bother pretending they had documentation.
Back in the day doing "man grub", getting a rude message to use info, then "info grub" and getting a "grub is wonderful LILO sux" message and no documentation was definitely one of those moments where I wanted to beat somebody's head with a model M keyboard.
At least "pinfo" can be used without having to spend more time working out how to use the info tool than reading the documentation.

HTML from the 1990s

[tepples]

The 1990s, when HTML documents were readable and not stuffed to the gills with ads and social recommendation detritus. Really all a plain-jane HTML document is missing is a max-width:36em on body to make line lengths sane and a width=device-width on the viewport to make tablets not render it zoomed out.

Re:Oblig oblig XKCD

[Unknown Lamer]

What I find interesting about this Perl rewrite is that Guile, ostensibly the official scripting language of GNU, has had excellent structured texinfo support 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:Perl hater

[tibit]

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.