Why I use Gnus: Reason #1

For the sheer language and wisecracks in the manual. For example

Gnus gives you all the opportunity you could possibly want for shooting yourself in the foot. Let's say you create a group that will contain all the mail you get from your boss. And then you
accidentally unsubscribe from the group. Gnus will still put all the mail from your boss in the unsubscribed group, and so, when your boss mails you "Have that report ready by Monday or you're fired!", you'll never see it and, come Tuesday, you'll still believe that you're gainfully employed while you really should be out collecting empty bottles to save up for next month's rent money.

With entries like that in the manual, even if you don't understand anything in it the first time around, you'll come back for more.

But then I'm one of those weirdos who can happily spend hours reading the manual, sometimes.

Shell scripting gotchas: value too great for base (error token is "09")

Staring at the screen doesn't help.

Rerunning the code another 5 times doesn't help either.

It's still the same error. And it had been working so well for so many days. The code in question

if [[ $SDAY -eq $EDAY && $SMON -eq $EMON && $SYEAR -eq $EYEAR ]]; then
    echo "Data is current for $value_set"
    break
fi

You know you're good at shell scripting when you start making elementary mistakes and enter brain freeze territory frequently. I mean, your code can't just stop like that, can it?

And slowly you wrack your brains to see what you should be looking at.

Finally you read the error message and figure out that this is something to do with the base system.

You google and smack your head and realise, the dates were being read as octal and like clockwork it fails on 09th of April. You start to think of all the code to strip leading 0s and suitably chastened you stick to a simpler version which goes like

if [[ "$EYEAR$EMON$EDAY" -eq "$SYEAR$SMON$SDAY" ]]; then
   echo "No deltas to be captured"
   break
fi

The dates have to match, so it doesn't matter if it is a string or number.

Overconfidence, the bane of a programmer.

Where did my read mails go when using Gnus?

This seems to be a standard question for new Gnus users(ummm....yeah, it was for me too when I started). And this is sort of answered in the FAQ too.

Because Gnus treats email too as a form of net news some of the defaults may not be acceptable to people who use Gnus as a mail reader. If you look at the FAQ entry, the suggestion would appear ridiculous that you press a key combination just to see all the messages in a mail group.

A more simpler method (is anything ever simple with Gnus?) is to change the Group Parameters of the group to make it the default behaviour that all mail messages are seen.

In the Group Buffer, against the mail group, hit G P and you'd be presented with a buffer where you need to enter the following elisp form. Delete the nil shown in the buffer and enter

((display . all))

hit C-c C-c

and you're done. Enter the mail group and you should be able to see all the mail messages whether read or unread. Another minor convenience you may like to have is to set it like this.

((visible . t)
 (display . all))

which causes the mail group to be visible even if there are no new messages to read. Though for a text based news reader, it will be apparent that this is not exactly convenient as you'd be spending time moving the arrow keys to navigate over mail groups with no new messages.

Rather it's easier to let Gnus tell you that there are unread messages. Unless of course, you spend time rooting through your old mails.

The whole section on reading mails is also quite instructive for other conveniences that you wish you had. At least, this question, is a real time saver and makes things easier on the eyes.

W w is your friend.

Have you checked the Emacs NEWS file?

When you download and install the latest Emacs release, always check the release notes by checking the NEWS file. This can be pulled up by hitting C-h n in any Emacs buffer.

The NEWS file contains all the changes incorporated in the current release and has all the feature list implemented in the major release number. So NEWS.21 will have all the information about 21.x releases and NEWS.20 about the 20.x and so on.

Why should you check the NEWS file?

Well, you really don't as most Emacs features will probably work the way you expect them to work. When you upgrade and some feature breaks(very rare), the first thing is to check the NEWS to see whether the defaults have been changed.

As was my case in

** The HOME directory defaults to Application Data under the user profile.

If you used a previous version of Emacs without setting the HOME
environment variable and a `.emacs' was saved, then Emacs will continue
using C:/ as the default HOME.  But if you are installing Emacs afresh,
the default location will be the "Application Data" (or similar
localized name) subdirectory of your user profile.  A typical location
of this directory is "C:\Documents and Settings\USERNAME\Application Data",
where USERNAME is your user name.

This change means that users can now have their own `.emacs' files on
shared computers, and the default HOME directory is less likely to be
read-only on computers that are administered by someone else.

When I copied my installation over without my .Emacs into a new machine, it was irritating to see it look under the above "Application Data" folder. A quick look at the NEWS file, sorted that out.

Then again, another feature which I think should not have been implemented(I think it encourages bad practices with OSes which are not well designed to work with file names with spaces)

** When Emacs prompts for file names, SPC no longer completes the file name.
This is so filenames with embedded spaces could be input without the
need to quote the space with a C-q.  The underlying changes in the
keymaps that are active in the minibuffer are described below under
"New keymaps for typing file names".

If you want the old behavior back, add these two key bindings to your
~/.emacs init file:

 (define-key minibuffer-local-filename-completion-map
           " " 'minibuffer-complete-word)
 (define-key minibuffer-local-must-match-filename-map
           " " 'minibuffer-complete-word)

The NEWS also has new features that have been implemented, bugs that have been fixed, popular lisp packages which have been folded into the main tree and deprecated support for various platforms.

Make sure you READ the NEWS file before reporting any bug too.

The coming Open Source Database wars

Well, it's the commercial vendors who will be duking it, rather. With the recent Sun acquisition of MySQL and IBM throwing some dough to PostresSQL, (Enterprise DB to be pedantic), things are getting interesting.

I think it has less to do with database feature sets and more to do with pricing. If I understand something about database licensing, it's done mostly on a per CPU basis or number of cores.

Pricing will determine what kind of technology adoption will happen on multicore chips. While increased performance may be got by putting 4,8 or more cores on the chip, the pricing done on a per core basis will undo all the technical advantages.

If two vendors have the same number of chips on similar systems but one has more cores than the other per chip and the pricing for the Oracle database is done on a per core basis.....you can see where this is heading.

Disaster, for all the technical progress made.

I think that's why SUN bought out MySQL; From Oracle's point of view, putting more cores on a single chip means less revenue as less chips/system does more now. The only way it can make money is to switch to a core based licensing revenue stream. That would mean, SUN's systems would come out costlier compared to a similar CPU based system from IBM, say.

SUN and Oracle has been close for years and the sudden acquisition must mean that the low end SMB market is going to get poached from Oracle.

Soon, expect new TPC benchmarks from SUN using MySQL as the database.

Then the message would be loud and clear to Oracle. As a matter of prediction, Oracle would cozy up to IBM and optimise things for their Power chips I guess.

Update: see this link for more confirmation.

Now, the EC gets interested in OOXML!

Actually no. Given the initial intent and final vote of the OOXML, the EC is now planning to look into the voting process itself.

A little too late now; a bit like the cops in the movies.

Even with all the clamouring, it'll take years for any allegations to be proved or falsified. By that time, OOXML would have become mainstream thus making it all moot.

Rather, the standard should be on indefinite hold till a consensus is reached by all concerned that Microsoft got the votes fair and square.

Who's going to complain about this?

Microsoft? Actually, they'd benefit as they have nothing to hide, wouldn't they?

The Open Source crowd? It's not a standard yet, till the allegations are proved either way, so they might have to wait a couple of years before they have a technical locus standi in this discussion.

That about settles it then?

*wink

All this will be apparent to those who've the "Yes Minister" series where the Minister and the Civil Services folks clash over policy.

Reading Digest mails with Gnus

One of the reasons why I use Gnus, is the ability to read mailing lists in digest form very easily.

Lots of mailing lists have the option of sending digests of all the mails sent that day, in a couple of mails (say usually under 64K) per day. This is better than having your mailbox inundated with hundreds of emails from the list. And delays the latest Virus/Bot attack too. :)

A digest mail is no different from another email, so most email clients treat it as another article or mail message. But if you open it, it's quite unappealing to read it. One huge text file, with mails separated by a newline. You'd have to scroll up to the TOC (generated from the Subject lines) to get the context and follows up in order to read. Especially on interesting mail threads, it's very irritating.

And to repeat it's all text. Imagine trying to read 64K chunks of plain text. I get around 8 in day on the sas-l list.

This is where Gnus shines. If you open the mail, Gnus opens it normally. Then hit C-d, Tada!

it's now splits the digest as individual mails showing each email by date and author. Just like you'd see any normal mail. And to boot, if you hit C-M-t, it threads the same digest to the extent possible(I mean, some mail threads can span digests, can't it?)

Hitting C-d is the only extra work involved.

This feature alone is the biggest time saver in terms of reading mailing lists for me. A quick glance at the threaded subjects of the digest and I'm ready to either read a few or simply exit the temporary buffer created.

Gnus is awesome in this regard.

The Impression I create with Gnus!

Sometimes I forget that Emacs is not a mainstream editor in India. And lots of folks haven't even heard of it.

Since I use Emacs for almost everything and the most common application I'm in, is Gnus, I get a lot of curious enquiries. Some are easy to divine while others are slightly weird where it's like there is a pregnant silence and you both wish the conversation had not started.

Is that a DOS application?

is the most common question. That is sort of OK, as I have white on black emacs screen and it probably is easy to mistake Emacs for a DOS application when glancing quickly(hah!)

Those who examine it a little more closely ask more questions. Earlier I used to say "Gnus", now I say my "mail client" and quickly add that I prefer plain text. The question which is asked

What is that?

At this point, UNIX guys nod their heads, Windows guys/Managers smile and others simply think I'm kooky.

Why?

Oh, I prefer the keyboard to the mouse, I say. It's easier to do this, that and that (vigorous hand waving by me) and getting a little animated.

You don't use insert mail app here?

No, you see it's a part of Emacs and Emacs is..... (even more excited and fast speech)

Why?

See, you can do PCVS, mail, Usenet.... (swivels around to Laptop and runs through a couple of keychords)

At this point, the newbies listen on, others look at their watch, while even more others mutter some excuse, and some say "nice" and wander on.

The hapless noob is well and truly in my clutches. :-)

You know vi, I ask?

Just started learning it, he replies.

Well, don't learn it, learn Emacs, I earnestly prod him.

Is it easy?

It takes about 6 months and after that it's easy I say. Faces fall; see, you'll have to unlearn CUA and relearn the Emacs way, terminology usage and all.

Is it Free?

Of course, I'll give my copy of it, I say.

Which is the last I hear from him.

I think I'm doing a terrible disservice to the FSF GNU Emacs hackers. World domination will have to wait.

Making CD images and ISOs on Windows

Thanks to cygwin, there is now a way to create isos and CD images on windows. You don't need to get those commercial software to create those images.

This list of software is what you'd need to work with to create, query and extract info from iso files.

Fortress 1.0 released

Saw this on gmane ; rekindled my memories on what this was all about. I remember the name Guy Steele and was thinking that this could turn out to be interesting language on High Performance Computing.

Check out the source page and as an emacs user, you'd be glad to know that there is also an emacs mode for it.

Will be downloading it and trying it out.