My Free Gnus Mug!

Lars recently posted on the Gnus mailing list that he had a few extra mugs and Tshirts and was willing to give them away for free. Well, I took him up on his kind offer and today I received his package.

A fine mug indeed. Now I have to convince my office colleagues of the earth shaking significance of the mug. :-)


Well....I'm not a good photographer.

Plotting tables in Org mode

A new tutorial has been added to Org-tutorials site explaining how to plot your org table data using gnuplot.   Another reason not to step out of emacs.

A Visual Bookmarks package for Emacs

When you use the default bookmarks feature in Emacs, those used to visual feedback on where the bookmarks are made, are let down.

There is none. Although the text based system is perfectly fine, lots of people would find a visual way to see their bookmarks as a better way to locate where they placed the bookmarks. At this point if you don't know what a bookmark is, it's best to read the manual link above.

Enter bm.el which is about as close you can get to mark up your code in technicolor!

Download and put it somewhere in your load path. Add the following to your init file

(require 'bm)

And a couple of customisations that you should set so that creation and navigation is easy. The author recommends

;; M$ Visual Studio key setup.
;; (global-set-key (kbd "<C-f2>") 'bm-toggle)
;; (global-set-key (kbd "<f2>") 'bm-next)
;; (global-set-key (kbd "<S-f2>") 'bm-previous)
you can also tinker with how you want the bookmarks to look like by using one of the following



(setq bm-highlight-style 'bm-highlight-only-line) ;;default, the last one in the pic

(setq bm-highlight-style 'bm-highlight-only-fringe) ;;middle bookmark

(setq bm-highlight-style 'bm-highlight-line-and-fringe) ;; the first one

You can customise the colours by using M-x customize-group bm and changeing the defaults.

One other function that should be useful is M-x bm-show and M-x bm-show-all; both show all the bookmarks set in the current buffer and in all buffers respectively. If you read the commentary of the elisp package, you'd see options to make the bookmarks persistent, annotate them, controlling the size of the bookmarks file etc.

While the default bookmarks bundled is more than adequate, this package is quite eye pleasing without getting in the way. At least for me, I tend to use this where I don't need persistence of bookmarks and throw it all off after I killed the code buffer.

Dired: Filter file names

If you want to see only files with certain extensions like *.sh, the simplest way to do it is C-x d *.sh to just show shell scripts.  This thread on gnu.emacs.help shows other ways of doing the same.  As you can see there are a number of ways to achieve the same but in my opinion, filtering it by passing the regex to dired is the easiest.

Changing fonts in your LaTeX document

In this discussion on changing fonts on comp.text.tex newsgroup, the reply might be useful in deciding which font to use where.  That is one of my biggest issues with fonts.  I have no taste. :-)

Given a large number of fonts, I'd unerringly chose the one font that would make folks gouge their eyes out with a blunt pencil, I swear.

Assuming what the author wrote is true and people are in general consensus, I'd take those instructions. Not being an expert in Typography, I'm hard pressed to come up with a good explanation of how, what and where different fonts make a good impression.  I used to compile my paper with different font packages to see which one appears good and by the time I tried my fourth font, I'd promptly forget how the first looked like.  Of course, I could have saved each font type and then opened all of them to compare but being the lazy person I am.....

That said, as the thread mentioned, it's better to use the font packages rather than trying to change the individual fonts for specific parts of the document.

Emacs 22.3 released

From the mailing list, we have the bug fix release of Emacs 22.3. In a couple of days, the Windows compiled binary should be available here, as I can't see it so far. And then it would be found in your favourite gnu ftp mirror site in a few days from now.

Building TeXLive Binaries on Cygwin

A few months ago I had asked about whether there was a cygwin version of the TeXLive system as the TeTeX system was no longer being actively maintained.

Today I received a response that it can be built successfully on cygwin , thanks to Angelo Graziosi. It might be useful for some. Please read the README so that you don't run into surprises. You have to download the lzma file and install it as suggested in the README.

As for me, I'm sticking with MiKTeX as it works without a hassle and the update feature synchronises all the packages I have installed already. If the cygwin maintainers add TeXLive to the official list of maintained packages, I'd change my mind. It's easier to keep everything under one roof than having to get it from ten different places.

So, if you want a cygwin version, it can be done.

Why I rarely try out other editors

This thread on the sas-l mailing list got me thinking on why I rarely try out other editors these days. Granted it is specific to the product but still, there are lessons worth learning from it.

If you see the litany of complaints in that thread, first off, you'd notice that in a code editor that is pretty much non graphical in its code presentation, you'd have few of the problems listed. Sure, you'd have to do a lot of pagination to paste and read code later on but you don't have to tear your hair out in doing so.

And if you were just that bit script savvy (not necessarily elisp), you'd be that much more productive and less error prone. The complaints listed are the ones that bug me too. I don't seem to know what is happening when the table structures are copied as graphical objects or some sort object is copied in these GUI heavy editors. And the dreaded mouse clicks drudgery in validating whether the structures are being copied correctly?

That'd kill me out of sheer boredom.

Partitioning the code, testing it in little pieces, assembling it in functional pieces are lost with these editors. Sure, you can do it but that comes with experience and I bet that you'd have to do the mappings and flows all over again while assembling it.

If it were left to an editor like vi or Emacs, cloning, copying and modifying large parts of code is easy with a bit of builtin functions or other Unix tools like sed, grep and bash shell. Notice that you are not forced to use the editors themselves if you want to? But with these new editors with their project folders and tracking, you'd have to hack it to figure out data structures and try figuring other means to edit the code. And it all goes awry in the next release of the editor.

The more you use the product editors, the more is the learning involved in relearning doing the same things because the menu options have changed. There is very little in applying what you've already learnt to be productive immediately.

That's partly the reason why people are pretty insane in sticking to Emacs or Vi. Compared to sheer frustration with a "smart" editor, these are plainly functional tools that are general purpose text editing applications that Just Do The Job.

You build on what you've already learnt with Emacs; the core functionality is always available in all the modes and you learn the mode specific behaviour as required. And being text oriented, you've got only yourself to blame for any "mysterious" bug that appears.....well, mostly.

Every new fangled editor comes with some new idea that makes it worthy in some respect but you seem to have to lose out a number of other features that makes you productive to use it.

I threw in the towel a long time.

Now, I just check out whether the same feature is available in Emacs in some form or the other.

Emacs 22.3 Pretest available

The second pretest of Emacs 22.3 is available here, that's for the windows version.

Understanding Emacs Mark and Point

Another terminology which brings some form of confusion to newbies is the term Mark and Point used in the manual and in descriptions of Emacs editing actions. Truth to be told, I too just had a fuzzy idea what mark was all about when I first started and took point to be where ever the cursor was currently.

Well, point is exactly that; it is the current position of the cursor on your Emacs buffer. And it's there in the Emacs Tutorial too.

The location of the cursor in the text is also called "point". To paraphrase, the cursor shows on the screen where point is located in the text.

So, what is mark, then?

Mark is the equivalent of dropping anchor or "marking" the start of a position in a buffer. One marks a position in the buffer and then moves the cursor to another point, delimiting a region. Thus, mark is primarily used to delineate a contiguous region of text in conjunction with point. The text between the mark and the point is the region where one can operate Emacs commands if needed.

Is there an order to mark and point?

No, from the manual

The ends of the region are always point and the mark. It doesn't matter which of them was put in its current place first, or which one comes earlier in the text--the region starts from point or the mark (whichever comes first), and ends at point or the mark (whichever comes last). Every time you move point, or set the mark in a new place, the region changes.

Now, I suggest you hit the manual link above to know everything one needs to know about mark, mark ring and traversing marks.