The closest to text intellisense in Emacs

Emacs users know that M-/ is used to the expand the text at point for possible completions. One good thing is that it searches all the buffers for possible completions. While this is not the same as programming language intellisense stuff you find in programming editors from Microsoft, Sun and Eclipse, it's still a better choice than a language specific offering.

Why? Because it gives the same consistent behaviour in whatever buffer you're in. You can be sure that if you had typed it before, it can be plugged into the current buffer in whatever mode it is in with a minimal of keystrokes. This is in contrast to other specialised editors which can offer the feature for Java, C or C++, say.

OK, the choice of M-/ is not exactly great for those who are not good typists.

But this is Emacs; there is a way to use TAB as the more natural keystroke to expand the text at point. Plugging in the code given at this link will make text expansion or completion a lot more natural. Having done that, I've pretty much stopped using M-/ for text expansion.

One other way to do text completion is to use Predictive mode which learns from your typing style; Having used it before, I could see the benefits but I ran into some resource usage errors with the dictionary and hence stopped using it.

I'd encourage people to try predictive mode if only to see the possibilities that might arise for you. A typing session that is customised to the way you write. It might be very useful for people who are in some specialised fields with limited but large words usage.

LaTeX tip: Always use small fonts for Verbatim environment

On the TeX newsgroup, this was a nice tip to use. Indented code tends to move off the paper with normal fonts and the only way was to wrap the verbatim environment under \small.

But you'd have to do that for every verbatim listing.

Making the change in the document preamble makes the code listing simple.

For those interested in more sophisticated LaTeX pretty printing, the listings package is pretty good and comes with support for a number of languages. For anything fancier than the normal verbatim environment, that is a very good package to use.

Cleaning up or Deleting LaTeX intermediate files using AucTeX

Anyone using LaTeX knows that there are a number of intermediate files that are generated in the course of compiling the document. After the final file is generated, there is no need to keep those files around. But one has to delete them manually or plug the extensions in a shell script to delete them.

Fortunately AucTeX provides a simple interface to clean the files. Hitting C-c C-c and typing 'Clean' or 'Clean All' deletes the intermediate files associated with the current .tex in the buffer.

That's right, it ONLY deletes the intermediate files with respect to the current buffer where C-c C-c is called.

The difference between 'Clean' and 'Clean All' is that, in the latter case, the output files are also deleted. And the files can also be deleted by calling M-x TeX-clean.

So, what intermediate files are deleted? Depending on the type of file being edited, it varies. For example, for LaTeX files, it's

LaTeX-clean-intermediate-suffixes is a variable defined in `latex.el'.
Its value is ("\\.aux" "\\.bbl" "\\.blg" "\\.brf" "\\.fot" "\\.glo"
"\\.gls" "\\.idx" "\\.ilg" "\\.ind" "\\.lof" "\\.log" "\\.lot"
"\\.nav" "\\.out" "\\.snm" "\\.toc" "\\.url")

To know the exact way things can be customised, see the AucTeX manual, especially Cleaning.

In my previous post, I outlined how to get Auctex to launch Acrobat Reader. Here's a minor change based on the same poster's advice. If the reader is the default application to view pdf files in Windows, you don't even need the acrord32 in the configuration. Just

TeX-output-view-style is a variable defined in `tex.el'.
Its value is
(("^dvi$" "^pstricks$\\|^pst-\\|^psfrag$" "dvips %d -o && start \"\" %f")
("^dvi$" "." "yap -1 %dS %d")
 ("^pdf$" "." "cygstart %o")
("^html?$" "." "start \"\" %o"))

is enough.

Making AucTeX launch the Windows Acrobat Reader

When I compile documents using AucTeX, I used to manually open and close the generated pdf by navigating to the file location and opening the file using Windows based Acrobat reader.

The Reader locks the file when in use, so if you recompile the document when the pdf is still open by the Reader, you'd get the "can't write to output file" error.

One workaround I used was, the cygwin based xpdf viewer which doesn't lock the file. But you'd have to refresh the file every time something changed, by hitting 'r' in the xpdf application.

The problem with the default AucTeX install was that it had the start "" %o as the entry for View which didn't do anything. Even though I don't use that feature, I thought, let's get this to point to Acrobat Reader and save it.

Turned out, you need to customise TeX-output-view-style. Setting it to

start "acrord32" %o
acrord32 %o

didn't work. Finally, one poster on the AucTeX mailing list give the answer which made it self evident. Since I was using cygwin, he suggested I use cygstart instead of start.

That worked like a charm and now my TeX-output-view-style looks like

Its value is
(("^dvi$" "^pstricks$\\|^pst-\\|^psfrag$" "dvips %d -o && start \"\" %f")
 ("^dvi$" "." "yap -1 %dS %d")
 ("^pdf$" "." "cygstart acrord32 %o")
 ("^html?$" "." "start \"\" %o"))

Gnus v5.10.10 is released

Just saw this in the Gmane newsgroup. A new version of Gnus has been released. Those using imap would be happy to know that the unread count should be coming out correctly now. At least that's what the Release notes claim. :-)

And the drafts editing has been changed to the more logical 'e', I see.

And there are a whole bunch of other changes. Since I've been tracking the CVS version, I've been thinking that these features were already a part of the bundled Gnus version.

That's the problem with bleeding edge; you think some feature is so obvious and when people ask about a certain feature, you keep wondering why they are not using the obvious menu option.

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.