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.
Will an end user notice this speed degradation? (Score:3)
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? (Score:5, Insightful)
Re: (Score:2)
Re: (Score:2)
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: (Score:3, Interesting)
Texinfo produces very nice paper manuals effortlessly. With Docbook one has to dive into XSL-FO unpleasantness.
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
So, nothing you'd care to run makeinfo on. Point taken. Er, what were you saying, again?
Things you don't hear every day (Score:5, Funny)
"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 (Score:4, Funny)
"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]
Oblig oblig XKCD (Score:4, Funny)
Lisp
http://xkcd.com/224/ [xkcd.com]
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:Oblig oblig XKCD (Score:4, Insightful)
Re:Oblig oblig XKCD (Score:4, Informative)
Re: (Score:2)
$ 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...
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]
Re: (Score:2)
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.
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. [xkcd.com]
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: (Score:2)
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]
Indeed [xkcd.com].
Re: (Score:2, Redundant)
That is pretty scary when you rewrite it in Perl to make it intelligible.
Re:Things you don't hear every day (Score:5, Insightful)
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: (Score:3)
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
Re: (Score:2)
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.
man texinfo (Score:5, Insightful)
Can't be much use, it doesn't have a man page.
Re: (Score:2)
It does actually have one on my system, though it points you to the texinfo page (of course) for additional details.
Re: (Score:2)
Default to HTML yet? (Score:5, Insightful)
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.
HTML from the 1990s (Score:5, Insightful)
Re: (Score:2)
This is perhaps the most informative thing I've read all day. Thanks!
Re: (Score:2)
What's wrong with that? ;)
Re:Default to HTML yet? (Score:5, Insightful)
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: (Score:3)
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: (Score:2)
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: (Score:2)
man://whatever
That works in Dolphin too.
Re: (Score:2)
HTML, entirely on one webpage [gnu.org] is available for every GNU project I have ever seen.
Perl??? (Score:3, Insightful)
Re: (Score:3)
Probably because it's the second most widely known and used language on systems that run makeinfo, next to C?
Re: (Score:3, Funny)
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: (Score:2)
Sure, enjoy...
http://mattsurabian.com/duckhunt/ [mattsurabian.com]
Re: (Score:3)
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: (Score:2)
GCC is C.
Not anymore. [slashdot.org]
Re: (Score:2)
Fair enough I meant it aims at low level high performance languages.
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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 stren
Re: (Score:2)
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: (Score:2)
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 a
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: (Score:2, Insightful)
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: (Score:3)
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.
Do not want (Score:5, Insightful)
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: (Score:2)
Re:Do not want (Score:5, Insightful)
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: (Score:2)
This, exactly this.
Re:Do not want (Score:4, Insightful)
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 (Score:4, Informative)
Re: (Score:2)
HTML that still renders legibly in a text terminal, that is. Test case: lynx
Re: (Score:2)
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.
Re: (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, a
Re: (Score:2)
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.
texinfo is good for writing documentation (Score:3)
Re: (Score:2)
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: (Score:2)
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 tha
Re: (Score:2)
Re: (Score:2)
The format exists because of the reader. It has no particular practical advantages vs. HTML so there's no reason for either.
Re: (Score:2)
IGGT 1/10
Re: (Score:2)
Kill yourself.
Re: (Score:3)
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
Re: (Score:2)
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 (Score:5, Informative)
Try pinfo [sourceforge.net]. From the description:
Believe me, it's a lifesaver for reading info pages.
Re: (Score:2)
Thank you! That was neat didn't know about that one.
Re: (Score:2)
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 (Score:5, Funny)
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: (Score:2, Funny)
You, sir, have no idea what the One True Editor actually is:
http://www.gnu.org/fun/jokes/ed-msg.html
Re: (Score:2)
Re: (Score:2)
Because lord knows, open source is all about choice.
Re: (Score:2)
Choice for the developer, not the end user. The end user is stuck with whatever the developer picked. ;)
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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.:
OK?
Re: (Score:2)
Right, and it's a lot nicer to read complex documentation through your web browser than through some clunky ncurses utility.
So... (Score:2)
How do you compile the documentation when you're building Perl's prerequisites from source?
oxymoron (Score:3, Informative)
Re: (Score:3)
...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: (Score:3)
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, ther
Re: (Score:2)
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 sec
Re: (Score:2)
*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 (Score:3)
Just an End User (Score:4, Interesting)
Google + Forums is what real people rely on.
Re: (Score:2)
I have always hated texinfo (Score:3)
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: (Score:2)
HTML 2 (Score:3)
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: Yes, spin it that way, why don't you. (Score:2, Informative)
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: (Score:2)
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.
Re: (Score:2, Funny)
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: (Score:2)
Breaking them against wheels until the right bits fall out, I'm sure.
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.
Re: (Score:2)
As an aficionado of old computers, I feel this strip really speaks to me...
Re: (Score:2)
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.