Slashdot Mirror
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.
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?
"Nobody could understand the source code anymore without massive doses of caffeine... ao we decided to rewrite the whole thing in Perl."
Can't be much use, it doesn't have a man page.
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.
Why on earth would they have picked perl? Perl isn't really a native gnu project. At least gcc is.
File under 'M' for 'Manic ranting'
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?
"Ignorance more frequently begets confidence than does knowledge"
- Charles Darwin
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.
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.
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.
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.
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
Lisp
http://xkcd.com/224/
...perl...cleaner code...
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.
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.
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.
Three Squirrels
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.
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.
Beta is broken and the link to classic doesn't work. Stop wasting our time or there won't be anybody left here.
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.
A successful API design takes a mixture of software design and pedagogy.