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

Will an end user notice this speed degradation?

[bogaboga]

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. (emphasis mine).

Whether a end user will notice, I don't know for sure! Who does?

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

Re:Will an end user notice this speed degradation?

[Anonymous Coward]

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. (emphasis mine).

Whether a end user will notice, I don't know for sure! Who does?

If you're typing man whatever, no, since it's run as part of the build process. Even if you're building from source, it's still going to be marginal compared to other steps.

Re:Will an end user notice this speed degradation?

[ais523]

It'd only be even potentially noticeable if the end user compiles their documentation from source. That's only likely to happen if they're also compiling their binaries from source, i.e. on source-based distros. (I doubt it'd be particularly noticeable even in such cases.) Most people would get the compiled version of the documentation, rather than compiling it themselves.

Re:Will an end user notice this speed degradation?

[Zontar The Mindless]

Hooray. Nice to see they finally got round to supporting Unicode. Structured docs. Woohoo. Multiple formatting backends. Yippee.

DocBook XML has had all these things from the beginning, and thus we (ubiquitous FOSS project) dumped TexInfo in favour of DBXML 6 or 7 years ago as the source format for all our end user docs.

I do not miss TexInfo one bit.

Re:Will an end user notice this speed degradation?

[Anonymous Coward]

I don't see speed as an issue here. What bugs me is the portability.
There are C-compilers available for a lot more platforms than Perl is ported to. This pretty much means that the documentation have to wait until someone decides to port Perl. (Yep, that sounds like a lot of fun.)

Re:Will an end user notice this speed degradation?

[Ed Avis]

What still-alive platform has a decent C compiler (crusty K&R ones don't count), but doesn't have a port of Perl?

Re:Will an end user notice this speed degradation?

[deepsky]

Texinfo produces very nice paper manuals effortlessly. With Docbook one has to dive into XSL-FO unpleasantness.

Re:Will an end user notice this speed degradation?

[Anonymous Coward]

Pretty much any platform that isn't Windows, BSD, Linux or Mac?

Re:Will an end user notice this speed degradation?

[Anonymous Coward]

texinfo is vastly nicer and much less verbose to read and write than XML. You made the wrong choice

Re:Will an end user notice this speed degradation?

[tibit]

So, nothing you'd care to run makeinfo on. Point taken. Er, what were you saying, again?

Re:Will an end user notice this speed degradation?

[K. S. Kyosuke]

Texinfo produces very nice paper manuals effortlessly.

With those changes and the advent of LuaTeX, perhaps it will be possible to produce even better paper manuals even more effortlessly. (But I still bet my money on Pandoc...)

Re:Will an end user notice this speed degradation?

[larry bagina]

Seriously? Perl Platforms

Re:Will an end user notice this speed degradation?

[cduffy]

There are also places where Perl is supposedly compatible, but an utter bitch to build.

Think about anything small enough you can't host your compiler there. The compilation process depends on being able to build and run miniperl, and a bunch of other tiny little test programs locally. If the system you're doing the compilation on can't run the target's binaries... well, it's an interesting day.

The truth about the Free Software Foundation

[Anonymous Coward]

Tabloid newspapers have speculated for years that Timothy Geithner is a prominent supporter of the Free Software Foundation. Too bad we didn't believe them sooner!

You may not know it, but the concept of currency inflation was invented by the Free Software Foundation, which wanted an easy way to increase the numerical value of their investments in MDMA. It's easy to tell that inflation was never really real: when things get older, they get run down and lose value, right? But inflation is about numbers getting BIGGER. It doesn't make any sense!

There's evidence that Reverend Al Sharpton's rise to power was engineered entirely by the Free Software Foundation, which profits from Reverend Al Sharpton's influence in ways we do not yet completely understand.

Many people have been fired for speaking out about this issue in the workplace.

You may think free speech ensures your right to talk openly about Timothy Geithner's true beliefs, but powerful people won't let that happen: in the past, brave citizens who have questioned them about these issues have been silenced with crippling libel lawsuits.

People who have taken out library books on this topic frequently find that they receive more rigorous airport screenings than before. Definitely not a coincidence!

"There are no facts, only interpretations." -- Friedrick Nietzsche

Re:The truth about the Free Software Foundation

[Anonymous Coward]

...the fuck?

Re:The truth about the Free Software Foundation

[Anonymous Coward]

woot woot

Re:The truth about the Free Software Foundation

[Anonymous Coward]

Someone is posting shit they get off of verifiedfacts.org

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

[Anonymous Coward]

seeing as it's perl, the next step is obviously: rinse. lather. repeat.

Re:Things you don't hear every day

[c0lo]

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

Oblig xkcd

Re: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."

Citation needed.

Re:Things you don't hear every day

[murdocj]

That is pretty scary when you rewrite it in Perl to make it intelligible.

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.

Re:Things you don't hear every day

[c0lo]

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.

Whenever the problem allows for a single pass.

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.

Due to limited contexts available on xkcd, I surmise we are quite far at that point. E.g. I challenge you to find the very basic "laser on sharks" or "car analogies" cartoons on xkcd.com.
"grits" (hot or not), "petrified/statue" etc??? Not a chance in hell.

Re:Things you don't hear every day

[Anonymous Coward]

Yes, but would you advice you kids to do the same?

Re:Things you don't hear every day

[Anonymous Coward]

Due to limited contexts available on xkcd

Due to the limited contexts available on slashdot I don't see how that would be a problem.

Re:Things you don't hear every day

[one eyed kangaroo]

Yes.

Re:Things you don't hear every day

[itsdapead]

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.

Indeed.

Re:Things you don't hear every day

[murdocj]

Yes Perl has lots of libraries, lots of code, lots of support, and I'm sure if you spend all of your time in Perl, you eventually get used to it. But I spent time working on occasion on some Perl scripts we used for glue, and from that point of view, Perl is a nightmare. Random crap done by random characters depending on random context. Basically it looks like whenever Larry Wall needed to do something, he added some functionality and assigned the next unused character combination to it. I've programmed in a wide variety of languages, down to flipping switches and pressing a button to put the next opcode into computer memory, and Perl is far and away the most annoying.

Re:Things you don't hear every day

[murdocj]

I must admit, one of my issues with Perl isn't really Perl, it's the Camel book. It seems to be deliberately written out of order so whatever you are reading, it's guaranteed that you need to read something later in the book first.

Re: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."

This might say a lot more about the ability of the reader than anything else.
I personally have found the vast majority of Perl programs that I've been forced to look at a pile of vague idiomatic expressions and mixed metaphors, even within the Perl language itself.

But, a program that was authored in 1987 and is just now in 2013 being rewritten to be slower - that's a good run for any piece of software, so so long, and thanks for all the fish.

man texinfo

[Anonymous Coward]

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

Re:man texinfo

[Trepidity]

It does actually have one on my system, though it points you to the texinfo page (of course) for additional details.

Re:man texinfo

[Anonymous Coward]

Maybe you should run Debian or a derivative? Debian are big on man pages and will write them if they don't exist.

Re:man texinfo

[Anonymous Coward]

Good joke, but, honestly, I much prefer man pages over texinfo anyway.

Except, of course, for those infuriating man pages that say nothing and point the user to texinfo.

article useful

[Anonymous Coward]

article useful thanks you
www.ingaz.net

Yes, spin it that way, why don't you.

[Anonymous Coward]

Consequence: Instant perl dependency on everything that uses texinfo. Which is bloody everything the gn00 bunch publishes. My, what an improvement. And info and its assumptions (including emacs-y default viewer) already was such a wonderful thing.

Re:Yes, spin it that way, why don't you.

[Anonymous Coward]

Only for building the software, and even then (at least with Automake) only if you are generating distribution tarballs or building from the bleeding edge vcs repository and need to regeneration maintainer files. If you're using Automake... it's already written in Perl. And it's basically a hard dependency in the base system of every GNU/Linux distro.

Re:Yes, spin it that way, why don't you.

[Anonymous Coward]

You sir, are full of it.

Automake does not depend on perl. Perl is not a hard dependency in "the base system" since this concept doesn't exist in "gnu/linux". And it isn't in systems where such a concept does exist, eg FreeBSD (the spurious and wrongful dependency on perl and python listed in the glib2 port Makefile notwithstanding, same with the braindamage brought by the new and improved Xorg with video driver(!) dependencies on dbus(!) and xcb on python).

It'd be nice if the FOSS world would be a little less careless about its veritable forestry of dependencies. Much of it is rather senseless and on balance not worth the trouble when looking a bit further than the happily hackening developer and his magnificent code mangling machine, like when accounting for the users.

Re: Yes, spin it that way, why don't you.

[Anonymous Coward]

You sir, are full of it.

Automake does not depend on perl.

$ head -n1 /usr/bin/automake-1.11
#!/usr/bin/perl -w

Perl is not a hard dependency in "the base system" since this concept doesn't exist in "gnu/linux".

Sure it does, it means the core, non-optional components of the OS.

Re:Yes, spin it that way, why don't you.

[Zontar The Mindless]

Sorry, but the world works the way it works, and does not magickally conform itself to your views on How Things Should Be.

I don't like perl, either. ("Loathe" might not be too strong a term.) But neither am I foolish enough to believe that I am likely to wind up with a usable Linux or FreeBSD system if I try to set one of those up without it.

Perl POD is a good man input format

[Anonymous Coward]

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.

Although I don't use Texinfo, it'll put another feather in Perl POD's cap.

Re:Perl POD is a good man input format

[jgrahn]

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: Perl POD is a good man input format

[Anonymous Coward]

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.

It isn't generated by Texinfo itself, it's generated from the Texinfo source by a custom script in the CVS source tree. The GP was talking about generating man pages using Perl's POD system, which is relevant to this article because Texinfo now includes a tool to convert from POD to Texinfo format.

Re:Perl POD is a good man input format

[Anonymous Coward]

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.

You've very nicely highlighted the barrier that is raised by using nroff -man directly. While it's not totally hieroglyphics, you need to pay careful attention to its documentation every time you use it because it's not obvious.

In contrast, Perl POD is much less cryptic, and is quite usable without reading anything at all. The barrier is much lower, and given the reticence that many people have in writing any documentation in the first place, that helps. As does its multiple back ends.

Perl POD is like the wiki of man pages.

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?

[Anonymous Coward]

have you seen the HTML that gets generated from TeXInfo? It's like you're time warped back to the early 90s.

Re:Default to HTML yet?

[ls671]

What's wrong with that? ;)

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.

Re:Default to HTML yet?

[Zontar The Mindless]

have you seen the HTML that gets generated from TeXInfo?

(Did they ever figure out how to output *valid* HTML? */me recalls many hours spent looking out over acres and acres of crossed and mismatched tags, and weeping softly to himself...*)

Plain old man pages (especially when nicely rendered in KDE's Konqueror web browser by typing "#program-name" into the URL box) ...

Fuck me! Been using KDE since 2004 and I had NO idea you could do that. (Works with Konq in both KDE 3 and 4, BTW.)

Thanks for the tip!

Re:Default to HTML yet?

[Anonymous Coward]

I the standalone info is fine it supports most of the emacs keybindings that I actually know off the top of my head

Re:Default to HTML yet?

[Lemming Mark]

Unless things have changed, I think you can also ##program-name and get the TeXInfo page for it.

With file management, web browsing, KParts rendering PDFs, and the integrated man / TeXInfo viewers I practically never used to leave Konqueror.

Re:Default to HTML yet?

[Anonymous Coward]

the standalone info is fine...it supports most of the emacs keybindings

Which is precisely why Info is not "fine".

I haven't used GNU info in over five years now (and that last time was out of pure bloody desperation) and I intend to keep it that way. GNU Info Must Die.

Re:Default to HTML yet?

[Anonymous Coward]

Personally I would prefer XML. It allows for using XSLT to transform the XML into just about any format you want, as well as opening up the option to make your own viewers using whatever XML parsing library you like best.

Re:Default to HTML yet?

[massysett]

HTML, entirely on one webpage is available for every GNU project I have ever seen.

Re:Default to HTML yet?

[flyingfsck]

Or perhaps more memorable:
man://whatever

That works in Dolphin too.

Perl???

[mark-t]

Why on earth would they have picked perl? Perl isn't really a native gnu project. At least gcc is.

Re:Perl???

[Darinbob]

Probably because it's the second most widely known and used language on systems that run makeinfo, next to C?

Re:Perl???

[Anonymous Coward]

Javascript? (ducks)

Re:Perl???

[ls671]

C and shell scripting is good enough for me and it should be for any GNU project. I do not use half-way solutions such as Perl. I use Java when bash and C becomes too messy. The idea is to reduce your inventory to a strict minimum.
 

Re:Perl???

[ozmanjusri]

Sure, enjoy...

http://mattsurabian.com/duckhunt/

Re:Perl???

[jbolden]

GCC is C. This is a job for a scripting language not a low level compiled language. Typically GNU uses Scheme as their scripting language. But knowledge of Scheme and Scheme syntax is decreasing. Perl has good support for parsing, tons of people know it, It seems like a reasonable choice for GNU to start doing scripting type stuff in. The Perl community has been active with free software for a long time and hasn't gotten involved in anything questionable.

Seems like a reasonable choice.

Re:Perl???

[Unknown Lamer]

Usually people make fun of the FSF for choosing crappy projects (see: bzr for emacs) because they are part of GNU instead of making pragmatic choices for technical reasons...

Re:Perl???

[Anonymous Coward]

> Typically GNU uses Scheme as their scripting language.

So you're basically telling: They have an "official" GNU scripting language, which they have been advocating for 20 years now, and now they are avoiding their own fucking dogfood and rewriting their core documentation format to depend on something outside of the GNU system? How is this different than, for example, Microsoft rewriting Office in Java? Fucking ridiculous.

> But knowledge of Scheme and Scheme syntax is decreasing.

Source for this bold statement?

Re:Perl???

[Anonymous Coward]

It's a new strategy to keep the code 'free' - write everything in a scripting language that you can't compile even if you want to.

Re:Perl???

[Xtifr]

How is perl any more "outside of the GNU system" than TeX? Which is, after all, what texinfo is based on.

The GNU project's goal is to implement a free OS. Not to re-invent every wheel. (Except for the kernel, but that's just follow-through--work on the GNU kernel started before other free kernels were available.) Perl has a GNU-compatible license--why shouldn't they use it?

Eventually, they'll make guile able to interpet perl code, and the problem will solve itself. :)

Re:Perl???

[HyperQuantum]

GCC is C.

Not anymore.

Re:Perl???

[jbolden]

Fair enough I meant it aims at low level high performance languages.

Re:Perl???

[mark-t]

Possibly... but here they just made a crappy choice period. And the fact that it's not even really part of GNU means that they don't even have an excuse for it other than ignorance.

Perl is not a remotely elegant or clean language to develop in, and I have completely lost count of the number of projects I've seen written in it, as they evolved, showed a distinct propensity to quickly *DE*volve into an undecipherable mess. It's a language that is best avoided in the 21st century, because there are many alternatives, equally free, and equally, if not more, useful.

Re:Perl???

[mark-t]

It isn't. But Perl is an utterly abysmal programming language choice.

The fact that Perl isn't even a GNU project means that they don't even have an excuse of wanting to stick with GNU for picking a crappy language to work with! If they were going to go outside GNU, there were dozens of free languages that they could have picked that would have been a better choice.

Honestly, about the only worse programming language choice I think they could have made is if they decided to redo TeXinfo in COBOL.

Re:Perl???

[Xtifr]

It isn't. But Perl is an utterly abysmal programming language choice.

I suspect the person who wrote the code disagrees--or else he would have used a different language. Working code trumps theoretical BS and religious language wars any day in the real world. If you hate perl so much, write your own version in your own preferred language, and offer it to GNU and see what they say. If you're not willing to put your code where your mouth is, though, then your opinion isn't worth squat.

And for the record, I disagree as well. Perl has plenty of warts, but it's got plenty of strengths as well. It wouldn't be my first choice these days, but it's powerful and expressive and can be perfectly straightforward. I do slightly prefer python, but I consider both languages fairly annoying, albeit for almost completely opposite reasons.

Heck, name a language, and I can probably give you a lengthy list of reasons why that language is an "utterly abysmal programming language choice". :)

Re:Perl???

[mark-t]

I'm generally not big on language bashing, but the biggest problem I have with Perl is with its complexity, having numerous operators and several special syntaxes. What this almost invariably means is that you can get short, but extremely complex code with many syntax errors which take some time to understand. Even worse, it often also means that reading someone else's code is difficult, and often maintenance of somebody else's Perl project can be an intractable problem. While it's entirely possible to write difficult to understand code in any language, everything that I have ever seen in Perl seems to indicate that the language, through its complexity and especially because of the many operators is possesses, practically encourages people to write extremely terse, and correspondingly highly obfuscated programs to all but extremely trained people who more than likely would have learned Perl when there weren't that many other options for things like web cgi.

But legacy code maintenance is generally considered an entry-level position, and it stands to reason that people maintaining the code that one writes today will not have as much experience the one creating it for the first time. As such, clarity is paramount. Perl does not achieve this.

I would maintain that this reason is an objectively valid reason to disregard this language as viable in the 21st century, where there are many other choices.... its best use today should only be that of maintaining older software that was already developed in it... not the writing of new stuff.

Speed.

[Atzanteol]

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:Speed.

[Anonymous Coward]

I love how a language that was "fast enough" in the '90s is now suddenly "too slow" in 2013.

No-one said it was "too slow", if they thought that they wouldn't have released it. They said it was slower than the C version, which is (presumably, as I haven't measured it myself) an objective fact.

Re:Speed.

[Sulphur]

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?

Help me Obi Gentoo Kenobi. You're our only hope.

Re:Speed.

[Anonymous Coward]

Must be a noob gentoo forum, then. Gentoo is not for speed, it is for the build system (lets you choose version of each library, mix stable software for base system and cutting-edge version of gui software, and easiest access to source code of everything and seamless patching of the code -- just let your patch in your local tree, it will be applied at every version bump), the widest configuration choices even for basic components of the system (systemd/openrc, udev/eudev), the text-oriented configuration, the developer-oriented desktop (you always get the "developer packages", I mean what other distros seem to call "developer packages" and scrap in default installs).

Perl hater

[Anonymous Coward]

Those script languages are for kids. Real men program in C, which is, basically, portable Assembly, the real deal.

Re:Perl hater

[Anonymous Coward]

Real men use an macros to create documentation.

Re:Perl hater

[Anonymous Coward]

That high-level C crap is for wannabes, son...real men create their programs in native binary by manipulating the bits on their drive platters with pointy magnets

Re:Perl hater

[Anonymous Coward]

Really? Gee, I always thought that real men saved the proving-their-manhood bit for when they're alone with their women, and during working hours just tried to write good code.

Re:Perl hater

[Anonymous Coward]

Manipulating bits on your drive platters is for wannabes, son ... real men create their programs by using butterflies.

Re:Perl hater

[gorzek]

Breaking them against wheels until the right bits fall out, I'm sure.

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.

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

[one eyed kangaroo]

I'm with you. The GNU folks we are told "in general, abhor man pages, and create info documents instead.". Tis a shame.

Re:Do not want

[ls671]

This, exactly this.

Re:Do not want

[Nimey]

Agreed. The worst is when a package has a half-assed manpage that points to the info documentation, and when you fire up info it's the exact same stuff as the manpage.

Texinfo should be retired in favor of HTML for when there's too much documentation for a man page.

Re:Do not want

[Anonymous Coward]

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:Do not want

[Anonymous Coward]

man works great for simple commands, but what about complex hairy ones like gcc or gdb (which are really applications), or even 'find'. Then man starts to break down. You want formatted documentation with examples with variables spelled with more than a single letter.

Re:Do not want

[Chris Mattern]

texinfo is good for learning the deep details of a product.

No, it's not. It is clunky and difficult to navigate. A set of linked HTML pages would be good for learning the deep details of a product. Texinfo is just crap.

Re:Do not want

[nielsm]

No, it's not. It is clunky and difficult to navigate. A set of linked HTML pages would be good for learning the deep details of a product. Texinfo is just crap.

Isn't that a property of the `info` reader and not so much a property of the format? The idea is good, the user interface is horrible.

Re:Do not want

[Nimey]

The format exists because of the reader. It has no particular practical advantages vs. HTML so there's no reason for either.

Re:Do not want

[Chris Mattern]

And what other reader is there other than 'info'? They should use the version of the idea that already some some (relatively) non-crap user interfaces available: HTML.

Re:Do not want

[Nimey]

Right, and it's a lot nicer to read complex documentation through your web browser than through some clunky ncurses utility.

Re:Do not want

[Anonymous Coward]

What I really fucking hate is when you read "this man page is a stub, for full documentation see the info pages", and when you do all you get is a texinfo'd version of the man page.

Re:Do not want

[Anonymous Coward]

exactly

fuck "info" pages

nobody likes or uses that shit

Re:Do not want

[Anonymous Coward]

There is never too much documentation for a man page. Just look at the Perl manpages!

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

[jones_supa]

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.

Thank you, sir. That's something I would have said myself precisely like that.

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

[jbolden]

Well you can use info to read man pages and then you'll know those keywords when you need them. :) But yeah texinfo is a pain.

Re:Do not want

[Anonymous Coward]

What obscure keyboard commands? They're just the keybindings for the help system of the One True Editor.

You, sir, have no idea what the One True Editor actually is:

http://www.gnu.org/fun/jokes/ed-msg.html

Re:Do not want

[jbolden]

Thank you! That was neat didn't know about that one.

Re:Do not want

[murdocj]

Because lord knows, open source is all about choice.

Re:Do not want

[Unknown Lamer]

IGGT 1/10

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.

Re:Do not want

[ais523]

info shows the manpage by default if the info documentation isn't installed. So what you're seeing is probably a packaging problem, where the documentation exists but, for whatever reason (perhaps you're using a Debian-based distro and forgot to explicitly ask for it), wasn't installed on your computer.

Re:Do not want

[ais523]

Regex search over the entire info document is something I use a lot, and HTML doesn't (natively) support. (Index search via typing the name of an index entry, and then jumping to other entries that match the same string, is another thing that HTML doesn't do well.) These are arguably deficiencies in HTML, and could be fixed with mindboggling amounts of JavaScript or by doing things server-side, but both seem to be missing the point to some extent.

I've been reading a lot of info pages recently, and learning the viewer was worth the effort (tip that helps a lot: 'l' undoes navigation commands, for when you've got completely lost due to pressing the wrong button). It'd be great if we had something that replaces Info without all its conveniences, but sadly nothing seems to have obsoleted it yet.

Re:Do not want

[Nimey]

Kill yourself.

Re:Do not want

[chronokitsune3233]

(warning: rant follows)

Nearest HTML manual...generated using info2html. Seriously, using the mouse will interrupt your workflow as well because it takes more time to scroll and slide and click than it does to press keys.

By the way, here's a quick list of key bindings for you:

• u: Up to the parent node if it exists
• n: Next sibling node if it exists
• p: Previous sibling node if it exists
• C-s*: initiate/repeat a case-insensitive forward Search throughout the documentation
• C-r*: initiate/repeat a case-insensitive Reverse search
• Arrow keys, Page Up/Down: move as expected
• C-n, C-p, C-v, M-v: Next line, Previous line, Page Down, Page Up
• Tab - move to the next cross-reference after the current cursor position
• M-Tab - move to the next cross-reference before the current cursor position
• Enter/Return - activate the cross-reference the cursor position is inside, navigating to the node to which it points

* - In the standalone info browser, it's actually a regexp I-search while in the info browser in GNU Emacs, it's just a string I-search; use C-M-s and C-M-r in GNU Emacs.

By the way, C is the Control key. Also, M is the Meta key, which is bound to the Esc key. You can also use the Alt key instead of Esc, but this may pass the key combination such as M-Tab as Alt-Tab in a GUI environment, so the Esc key works best.

Overall, both man pages and info documentation have their places. I personally feel that it's simply a case of knowing where certain information fits in a certain medium. You wouldn't use an encyclopedia to find a definition or a dictionary to learn about the variety of bears throughout the world, so why would you expect every bit of library documentation to be in man pages?

Re:Do not want

[Anonymous Coward]

Emacs

Re:Do not want

[fa2k]

It's weird, I've seen a reference to texinfo many times while using man, but I have never actually followed through. Texinfo was just the weird disclaimer on some man pages to me. I just did info grub now, and it's not that bad if you stick to page up / page down and searching, like with man. Maybe I'll start actually using the texinfo pages now...

Re:Do not want

[Anonymous Coward]

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.

If you actually read the documentation, you would find that there is a "--vi-keys" flag to the standalone info reader allowing you to use the same keys as less/vi/etc.

Re:Do not want

[Anonymous Coward]

WhineWhineWhine

all you really need to browse info docs (on a default ub untu install ) is
-arrow keys (cursor movement)
-enter key (follow link)
-'u' (go one level up)

Now that's not so very hard now is it?

And it is *much* better than html manuals, (doxygen *shudder* ) where each manual has its own conventions and I need to use the mouse to browse through.

HMTL could do the job , but you would need to agree on a default subset of html, and a default formatting with a clear hierachy. And I would like a viewer which supports better keyboard navigation. I suppose HTML + conventions + lynx could emulate info, but the main advantage of info is that it forces everybody to use the same layout.

All the whiners are just scared when they see a textmode app :-)

Re:Do not want

[flyingfsck]

Goddammit, and I thought edlin was bad.

Re:Do not want

[gorzek]

Choice for the developer, not the end user. The end user is stuck with whatever the developer picked. ;)

Re:Do not want

[Rozzin]

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.

Then just pipe it through your pager, and you'll have basically the exact same experience as if it was a man page. e.g.:

info info | less

OK?

Re:Do not want

[Anonymous Coward]

Why aren't you using BSD?

Re:Do not want

[Trogre]

HTML that still renders legibly in a text terminal, that is. Test case: lynx

Re:Do not want

[Nimey]

Naturally. I wouldn't necessarily restrict it to just lynx, though; there are at least two other families of decent ncurses browsers (links, w3m) and they can handle complex pages better.

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:HTML from the 1990s

[tibit]

This is perhaps the most informative thing I've read all day. Thanks!

Archaic and unfree.

[Anonymous Coward]

Who needs this? Why?

Who prints to dead trees these days?

Better to use the modern Web stack instead.

WebKit / Chromium has an almost-entirely-copyfree implementation of HTML5, SVG, MathML, etc.

For an easier syntax there are things like Markdown.

For ye olde UNIX man pages, there's now mandoc.

--libman

begin sequence

[Anonymous Coward]

anus fist homosexual cunt ballsack fist anus nigger nigger cock jew whore jew ba
lls cunt whore ballsack whore fist fist faggot ballsack whore jew whore nigger c
ock cock cumdumpster balls fist fist ballsack whore nigger nigger faggot whore a
nus homosexual anus cumdumpster nigger faggot fist jew fist cunt balls jew

17756 79381 27294 76838 32554 94756 53144 70548 80716 71935 37379 81148 38959 76
512 62366 45969 21044 11918 36005 08919 59034 92848 71711 93083 01338 80586 7387
7 89886 64880 45218 24911 22806 21329 34869 08518 10439 58693 96930 95371 51840
61373 11195 59798 76827 86577 89579 40241 01795 85277 93761 18494 80950 12740 78
847 77112 40807 90258 25939 22808 01101 33210 32938 22863 13312 33626 21153 1522
2 37378 64479 90469 17092 09054 01796 01165 05574 70275 08240 96653 48102 96185
19920 20621 26464 60360 44932 32175 36405 86305 83852 59137 83036 63872 95037 03
461 26606 50632 24642 23049 63519 52062 97781 08687 33048 25342 39364 90235 8771
3 92895 94422 68032 14543 01948 65492 82238 78918 25829 93028 81910 36625 16205
94377 02873 87562 69027 23695 81669 09437 58843 00931 67147 38473 69937 58847 30
102 67584 60758 48581 94833 93305 12718 95706 83164 29518 48356 86135 62349 3424
4 66486 37638 77317 52964 03858 29993 43959 29541 91432 00790 18490 94864 24295
88712 37725 49907 72465 08551 18382 60898 32663 26059 28285 42129 40024 94798 84
931 39015 02210 48247 00799 57587 29196 80222 67530 84196 02536 96284 95199 2194
6 25313 62630 26640 13517 41838 38579 95896 58604 99042 78495 23914 62800 09199
30156 65303 53050 50230 53988 62350 24862 74544 06904 21458 80626 25727 10946 64
895 66877 68565 84291 93328 32071 96394 48640 06335 99386 68109 50399 90974 0455
4 82383 53065 82283 99158 33462 49700 24449 23105 81145 20932 82284 75183 99793
05851 26075 29222 08440 95023 46620 38386 70606 34554 87952 47702 17692 73572 01
744 36237 16598 90803 18270 64931 47846 78343 15816 21735 08238 83035 06294 5037
6 37861 42799 62330 32774 25939 44678 70521 43814 46053 15117 04516 35634 60348
91141 74162 70341 26760 00477 38669 10230 84862 10187 87034 22160 18006 36932 76
319 24072 37565 73035 31775 65505 41044 80492 85569 52283 27407 60396 11810 4755
5 26798 71079 97538 95464 05313 55631 96942 09456 45287 69057 86723 05727 90486
98692 14054 68005 76122 84733 98104 65488 69244 16862 55238 92808 67529 84184 91
120 54578 68429 14449 11482 84803 68585 23521 37689 77768 53204 81615 41582 5395
9 28105 57253 77549 95622 77495 63696 65598 26767 67330 15206 63477 86697 67503
20714 48442 53148 95666 87857 49732 23427 31770 82019 07343 34705 38182 96453 33
090 69119 67634 73205 05398 23066 46262 90033 31706 99758 25615 38517 83728 1573
3 21848 99087 25453 66753 22482 24970 70744 99254 21631 16124 31008 70852 44935
30486 63541 87837 77898 45797 96401 79369 27352 11950 45224 89680 96373 00155 19
541 22090 33530 92300 34246 03655 45738 20742 89174 84498 61972 75445 85470 5110
6 41184 10418 57743 43728 74755 67363 86079 05558 49183 78348 41290 21475 69237
80061 23211 57574 59446 50712 36258 43395 37980 44348 02947 03808 00360 98730 34
809 34116 36540 65848 85228 85039 49685 82058 39798 39808 68610 41816 32863 8729
0 05113 10440 87284 03334 87358 84844 53205 32057 11429 48948 07974 94013 92650
57902 00862 31497 62034 35404 40616 53674 43459 51054 35964 42099 63634 78044 62
734 32911 50284 99620 78986 02533 47341 82661 44060 40634 01577 70015 59589 5298
1 86902 04308 95173 87437 99376 15664 35838 60970 02191 81695 95067 00592 63489
58558 63076 16017 62846 76475 58698 60784 18608 33350 84698 06559 70119 28793 55
714 07616 36750 27365 13658 00783 66320 54279 69077 22186 04668 80202 97421 0122
8 69401 60757 14062 72654 33074 79353 75185 23606 28590 07455 65676 07463 41565
62372 51312 67178 59621 76052 25602 45966 85326 73680 19029 58570 18732 93616 60
038 76972 53088 70397 45807 32395 93356 48935 10024 60964 11095 59717 59138 5322
0 00889 40805 85557 87272 22875 65443 77669 14290 68326 12161 39408 17631 2301

Re:begin sequence

[Anonymous Coward]

whore ballsack nigger anus cumdumpster balls nigger fist whore balls nigger homo
sexual jew balls cunt jew ballsack jew cumdumpster whore faggot cunt whore balls
balls cock whore cunt homosexual cunt ballsack anus anus cunt faggot whore whor
e ballsack cock homosexual fist cumdumpster anus cumdumpster whore ballsack fagg
ot cunt whore balls

19992 30609 26349 07420 65359 67603 09076 76745 71294 76543 78147 03766 44904 37
543 06153 54337 75531 19367 01426 73220 03173 83077 63676 54538 06641 18655 3430
5 45429 51624 80504 32835 71448 74680 27434 71575 80642 33003 83900 99832 16507
44914 38080 65188 54151 26884 43910 31600 16503 52003 30372 48694 23509 56187 54
548 04437 03143 64962 35323 97990 44146 84462 87119 66483 14378 00594 05859 9913
3 81672 57630 39050 02393 31208 71004 94492 46187 17632 16158 23494 68590 27846
52342 46600 39370 02245 71024 57354 34648 91288 53093 54174 82479 47498 78216 35
197 38478 78091 15809 70566 50393 50162 08564 92761 01520 14009 93725 11216 8360
4 91039 85291 53637 36689 92659 13327 55961 63607 55655 60075 40338 94637 09232
04733 73098 37675 35081 08717 84941 06246 39629 13301 94367 52603 40935 44208 24
263 40581 77779 54023 97754 01689 04015 34583 00233 92812 00209 12039 29823 4205
1 82218 13526 09462 62817 50020 25997 32729 12176 00290 39715 04653 95903 25956
60902 37242 41935 62647 11008 34504 78347 51447 98265 60398 45013 43498 60273 11
007 69096 86860 48297 86451 44162 75448 93591 02133 30063 68247 33003 86265 2426
8 81074 22809 67551 37871 19422 23912 63326 84841 76456 73018 37218 50508 18056
32472 19838 52279 17871 87545 66556 59475 22923 58674 19830 58867 44218 87147 89
985 74271 91997 11328 80378 69128 20473 69006 21413 95428 22162 02253 14056 5970
0 60766 25621 57692 29508 26105 78999 00875 23027 90032 27459 94440 07033 63854
77863 08354 67796 30817 99586 02322 13926 73974 00630 38036 04376 29015 31887 14
919 76035 84269 77273 18955 34887 42443 65824 75515 07454 06595 29120 05602 8733
8 68433 72017 41608 45082 76697 71710 82598 56806 33709 19841 07517 24583 88025
03061 83914 44817 35523 52656 16298 03500 71291 24482 14093 20823 13962 68551 41
349 75395 45161 32820 06654 00355 55943 91215 57740 87554 26440 95791 74894 7820
9 38474 25658 31844 01891 81289 38336 01085 72408 57508 64350 97435 43364 16401
45850 37640 48986 75367 27416 02360 69656 28494 25763 79657 08670 86306 98814 51
606 82212 89288 94184 23999 48238 87947 79151 28801 29900 86020 30410 18361 5340
3 62444 35203 78821 95613 22577 18240 76989 13456 03287 63489 48405 29875 63477
66207 00573 37911 34200 09041 36933 32266 10561 00440 73941 97994 18468 63175 23
452 83150 11644 30097 50981 72371 49129 15230 00724 62325 47871 06668 63636 7694
8 32293 47135 27033 94121 68503 24809 88792 42732 72528 48526 41875 34245 23867
34116 41230 22807 53720 88983 17154 15324 61705 39940 36920 66278 90258 84050 45
868 70422 28329 63333 94091 41375 09828 96122 14804 36296 89596 84299 34748 8617
5 19351 62350 08808 47946 27939 05076 32839 80252 35840 88422 66491 99017 66068
64041 53951 27091 22301 47071 39740 53444 59180 65002 99874 79898 83743 08290 38
374 21318 74895 04340 32093 79656 95814 75246 62660 00659 19584 51124 88650 2658
6 68612 43772 34107 86864 42306 64094 67445 22988 89675 36888 11827 08517 69901
49307 25294 04027 68506 39840 30920 12844 37887 89451 45557 01215 28599 50834 42
797 53052 98757 69589 99882 68431 96514 04958 57524 66515 87023 85643 54308 6555
2 15812 45716 57036 89978 15442 91365 30189 64255 70228 42093 64729 07465 31592
46996 52220 25558 47436 58513 07778 26123 71261 88085 78930 01246 86924 54501 36
169 09055 45615 62554 80049 79653 34058 27042 29006 95228 19960 60734 63765 0243
0 49933 55477 88888 53651 27732 38621 34599 75813 79941 69557 64990 13502 32491
42180 71331 37146 00332 70344 57663 52848 02661 34338 34641 83765 86603 77460 15
055 50645 50855 74412 65849 68417 18623 90205 64367 83622 73675 96891 60293 8642
0 97639 23766 98369 29102 17152 73141 9779

It would be nice if...

[Anonymous Coward]

Textinfo actually said anything useful. Man certainly isn't the best documentation on the planet, but fucking hell, document command line switches, at least.

Re:It would be nice if...

[Anonymous Coward]

PowerShell is super. Detailed documentation, always plenty of good examples.

So...

[viperidaenz]

How do you compile the documentation when you're building Perl's prerequisites from source?

This reminds me of a Dilbert strip.

[sidragon.net]

Let me get this straight. These guys ported and anachronistic piece of software from one dead language to a slightly less dead language, and then bragged about using structured programming techniques as a feature.

Hang on, I think Scott Adams has something to say about this.

http://dilbert.com/strips/comic/2013-02-11/

Re:This reminds me of a Dilbert strip.

[Trepidity]

As an aficionado of old computers, I feel this strip really speaks to me...

Re:This reminds me of a Dilbert strip.

[JDG1980]

Let me get this straight. These guys ported and anachronistic piece of software from one dead language to a slightly less dead language

C is by no means a dead language.

Re:This reminds me of a Dilbert strip.

[Anonymous Coward]

Perl is dead. Well, not so much dead as very much alive. Hundreds of thousands of people can dance with Perl, dance around in circles, around the people who claim Perl is dead... Getting more and more user groups and workshops and conferences every year. Proud to be Perl.

Re:This reminds me of a Dilbert strip.

[Anonymous Coward]

Don't feed the trolls. Let them die hungry. Dead trolls are the only good trolls.

Re:This reminds me of a Dilbert strip.

[Anonymous Coward]

Great! That means you're no competition to some of us who've figured out that modern tools save time and facilitate higher quality products. While you're busy figuring out how to publish rich REST APIs or tracking down a memory leak, the rest of us will be shipping software.

Enjoy your GDB sessions.

Oblig oblig XKCD

[swm]

Lisp
http://xkcd.com/224/

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:Oblig oblig XKCD

[TheRaven64]

Being the official anything of the GNU project pretty much guarantees that no other part of the GNU project will use your stuff.

Re:Oblig oblig XKCD

[LizardKing]

Whenever I install Debian or a derivative of it, I always find it includes Guile, but that no packages depend on it. The only reason it exists is because RMS didn't like Tcl, which was the up and coming glue language at the time. Despite its shortcomings, Tcl was a very nice language to extend, whereas Guile was (and probably still is) an incomplete dialect of Scheme that only satisfies the Lisp obsessives.

Re:Oblig oblig XKCD

[fatphil]

Debian stable:

$ dpkg -l | grep guile
$

To be honest, I have written a few programs in tcl, and it was a very clumsy syntax that I had to fight with constantly. I have better experiences with LUA, but wish they'd stopped adding "meta" smarts to it earlier than they did, they went a bit over-the-top.

Of course, in the real world I just hack everything in Perl still no matter what other scripting languages come and go...

"Cleaner code" and "Perl" on the same paragraph?

[Anonymous Coward]

MWHAHAHAhahahahHAHhaHahAHahAHahAHa.

oxymoron

[csumpi]

...perl...cleaner code...

Re:oxymoron

[tyrione]

...perl...cleaner code...

True, not to mention with C11 you get Unicode and much more. C resurgence as a popular language is widely quantifiable. Perl as a dying language is widely quantifiable.

Re:oxymoron

[arielCo]

No oxymoron here. Perl frees you to create real messes, but that's mostly because it's very expressive, which also helps you code with less temp variables, shorter loops, etc., which can be actually easier to read if you know the language (Perl has a higher "cognitive load" than other languages that may alienate casual participants).

OTOH there are best-practices and style guides to ease things for the next lucky person to read your masterpiece (possibly a future you). So don't blame the language; hell, there's even a module that critiques your code.

So with some discipline and common programmer smarts you can write succint code that may be more readable than "fluffier" implementations. In practice, I've found that in any language, superfluous steps and variables, bad naming, and not-so-logical flow is a bigger penalty to readability than anything else. No language forces good style on you.

Re:oxymoron

[Anonymous Coward]

Having too many ways to express the same thing and a huge amount of implicit meaning IS the weakness of Perl.
That's what makes it so hard to write clean code in Perl, even worse than C. You just detailed why we understand this as an oxymoron.

Re:oxymoron

[Anonymous Coward]

Just because there's more than one way to do it, doesn't mean you should do it every way. Quoting from the wiki:

[T]he point is to use the first way that occurs to you. Often this will be the SimplestThingThatCouldPossiblyWork, and any given programmer will probably be fairly consistent.

Re:oxymoron

[arielCo]

That TIMTOWTDI meme is somewhat exaggerated, and not the same as expressiveness (which is what I was talking aboui). Likely, among the 3-4 ways that you may find to do something, some are obsolete or too complicated, some are misleading to anyone else reading the code, and you're left with one that's simple and "natural" for your purpose. Let me explain:

for ($i = 0; $i < $#names; $i++) {
    . . .
    $names[$i] = transform( $names[$i] );
    . . .
}

An atavism from C, unneccessary in Perl.

map {
    . . .
    $_ = transform($_)
    . . .
} @names;

As the name suggests, map() is most useful to do something (hopefully short) to every member of a list and get a second list with the results, at the price of putting your variable at the end, so why?

for (@names) {
    . . .
    $_ = transform($_);
    . . .
}

A-ha! Plus, if you're already using $_ because you're inside a typical while(<>){...} loop, you can always use another variable for iterating through @names.

This "good taste" is acquired after a bit of experience. Maybe it's a bit like cooking - you have so much available and no book could tell you all good combinations or all the bad ones.

Re:oxymoron

[Anonymous Coward]

As if that's a defense. You've obviously been drinking the same kool-aid as Larry Wall. "Perl is very EXPRESSIVE, that means it's of course very easy for someone to write Perl that works but is a completely unreadable mess! That's not a problem, it's a FEATURE!"

"Higher cognitive load," indeed, this whole post smells like a load. Probably related closely to the orifice you pulled that explanation out of. Python, there, a language that forces good style on you for better or worse. I don't even like it, but at least if you read a mess of a Python script you know it will be indented properly. Thank heaven for small miracles, and dead Perl programmers.

Re:oxymoron

[Anonymous Coward]

Don't feed the trolls who try to feast on Perl... since Perl is very much alive and will feed of dead trolls, like it has to be.

Re:oxymoron

[arielCo]

*sigh* ... I can hardly defend something that's not under attack. I posted some information that may or may not be useful to someone afraid of Perl, and it's up to said person to consider it, take it at face value, or throw it away with prejudice. Everyone is free to use it even if someone else hates it or trolls against it, and I'm happy using it for what it's good for. Cheers.

perl dependency

[manu0601]

Now we will have a perl dependency for all GNU stuff, and this to read documentation that is even less nice to read than man pages. The best thing they could have done to texinfo is to get rid of it, IMO.

Re:perl dependency

[Anonymous Coward]

Now we will have a perl dependency for all GNU stuff, and this to read documentation that is even less nice to read than man pages. The best thing they could have done to texinfo is to get rid of it, IMO.

You do realize that this dependency is:

• Only needed to build the documentation, and
• Man pages, as a rule, aren't hyperlinked, and are generally more concise.

Re:perl dependency

[Anonymous Coward]

automake already depends on Perl.

Re:perl dependency

[manu0601]

Right, I did nor realize it was only for building the doc. The info(1) command is still in C?

Man page concision is an advantage, IMO. The info pages are so confusing that I never use them. When I need some GNU in info format, I read it online using a browser.

texinfo is good for writing documentation

[Per Bothner]

Texinfo is is a decent format for writing documentation in - nicer and less verbose than HTML or DocBook. You can generate either HTML or DocBook or XML from Texinfo, and then do a bunch of processing on it. For example the documentation for Kawa is written in texinfo, then makeinfo converts it to docbook, which is then converted to html. The result isn't splashy but (if I say so myself) fairly nice.

Re:texinfo is good for writing documentation

[Anonymous Coward]

It looks like vomit but at least it's a bit easier to navigate.

Re:texinfo is good for writing documentation

[Zontar The Mindless]

Texinfo is is a decent format for writing documentation in - nicer and less verbose than HTML or DocBook.

You have got to be kidding. That's true only in the sense that making the trip from Stockholm to Vladivostok via dogsled might be a "decent" mode of travel.

Aside from the fact that it's Just Plain Horrid(TM) to read or write in source format, TexInfo suffers from the same problem that HTML does: No semantics.

The reason that DocBook is so "verbose" is that it actually indicates what things are.

And knowing what things are can be very helpful.

Re:texinfo is good for writing documentation

[Per Bothner]

Aside from the fact that it's Just Plain Horrid(TM) to read or write in source format, TexInfo suffers from the same problem that HTML does: No semantics.

You don't seem to know much about Texinfo. It is definitely very much about semantics - quite like DocBook. I agree DocBook takes the semantics thing slightly further than Texinfo - but it has big holes too: For example DocBook doesn't have a standard way to specify the structure of a command/function synopsis except for the C language.

The reason that DocBook is so "verbose" is that it actually indicates what things are.
One reason DocBook is so verbose is because it is XML, which by definition is verbose and human-unfriendly.

I've written plenty of documentation in both Texinfo and DocBook. They're both reasonable formats, but it is clear that DocBook is very tedious if you have to write it "by hand" rather than use a word-processor. Texinfo is much easier to both read and write, and it handles the "semantics" pretty well.

Re:texinfo is good for writing documentation

[fatphil]

It's clear that DocBook was written by a couple of groups who each had their own documentation needs in mind. So firstly there are more-than-one-way-to-do-similar-things clashes, and if you're not trying to write something that's just like one, and only one, of theirs - you'll end up with a bit of a 3-legged camel.

Just an End User

[rueger]

I very happily gave up on man pages (and variants thereof) years ago because they were too obtuse and circular to be useful to me, a mere end user. Early on I figured out that the basic rule of man pages was that the one you need relied on you already having read and digested fifteen others, each of which relied on you having read an digested fifteen others.... actually finding what you needed was an endless exercise in frustration.

Google + Forums is what real people rely on.

Re:Just an End User

[Anonymous Coward]

You mean Google+Forums people rely on other kind people who have read the man pages. Great way to build a civilization.

Re:Just an End User

[flyingfsck]

Oh my goodness, you also started with Caldera. I salute you my dear sir...

Re:Just an End User

[Anonymous Coward]

That's kinda what compiling things that rely on a lot of libraries from scratch feels like, except that after 5 hours of getting it to "compile" it'll just show some error nobody can possibly understand and you just give up and delete the working folder, just to try again the "right way" and get the same results.

Re:Just an End User

[Anonymous Coward]

Google + Forums is what real people rely on.

So man/info users are what, cartoon characters?

Compile to HTML instead

[Anonymous Coward]

That would have been a lifesaver...

I have always hated texinfo

[e70838]

It has been used as a pretext for not providing correct man pages. For example man sed:
COMMAND SYNOPSIS
This is just a brief synopsis of sed commands to serve as a reminder to those who
already know sed; other documentation (such as the texinfo document) must be con-
sulted for fuller descriptions.

When I have learned unix, man pages were complete, concise, accurate and uptodate documentation of all the system. I feel that because of this textinfo mess, man pages on Linux are incomplete and vague and that the documentation dislayed by info is not very clear.

Re:I have always hated texinfo

[Anonymous Coward]

When I have learned unix, man pages were complete, concise, accurate and uptodate documentation of all the system. I feel that because of this textinfo mess, man pages on Linux are incomplete and vague and that the documentation dislayed by info is not very clear.

Have you tried to continue using unix?

Re:I have always hated texinfo

[Anonymous Coward]

To be frank: if it's man pages you want, the very best Unix-alike OS out there is probably OpenBSD (maybe one of the other BSDs.) They consider man pages to be the definitive source of information on their userland utilities; if a man page is wrong, or missing information, it will be fixed when it gets noticed.

Linux's man pages are very hit and miss, which is a very real shame.

Re:I have always hated texinfo

[e70838]

This net bsd documentation of sed is incredibly better that the one I have on Linux. It is almost perfect. In 5 minutes, I have found only one point of ambiguity: it says it is a superset of posix.2, but I do not find the possibility to use a dash instead of a file to mean stdin. Maybe there are others issues, but this is clearly a better documentation (should I switch to netbsd ?).

Re:I have always hated texinfo

[Anonymous Coward]

You should find man pages to be roughly the same quality on any of the four major BSDs, so you are free to choose. Subjectively, I'm finding OpenBSD's and NetBSD's to be the easiest to read.

(GNU has a beef against man pages -- many of their utilities have zero. They've been betting heavily on texinfo for the past ten plus years.)

HTML 2

[SgtChaireBourne]

I'd rather see the format scrapped and replaced with either better man pages or else HTML2. With HTML 2 you can use a text based browser like Lynx, which is more polished and gives you better navigation capabilities. There are also more modules, libraries and packages that can work directly with HTML, so less time is spent trying to reinvent the wheel.

Comment removed

[account_deleted]

Comment removed based on user account deletion