Typewriter scroll mode in vim

I came across a Mac specific application Writeroom for distraction free writing and couldn’t help wonder that good ‘ol vim provides the same features.

One interesting feature was "typewriter scroll mode", in which, the line that you are writing is always in the middle of the screen. At times, while editing long files, I find myself too often at the bottom of the screen at find myself typing zz to redraw the buffer so that the current line is at the middle of the screen. It would be nice to have that as default. A quick search of the vim help revealed:

'scrolloff' 'so'    number  (default 0)
            global
            {not in Vi}
    Minimal number of screen lines to keep above and below the cursor.
    This will make some context visible around where you are working.  If
    you set it to a very large value (999) the cursor line will always be
    in the middle of the window (except at the start or end of the file or
    when long lines wrap).
    For scrolling horizontally see 'sidescrolloff'.
    NOTE: This option is set to 0 when 'compatible' is set.

So, the solution is:

set scrolloff=99

Maintaining ConTeXt Minimals on Arch Linux

On Linux, and to a slightly lesser extent on Windows and Mac, TeX Live is the de-facto TeX distribution. However, TeX Live is not satisfactory to a ConTeXt user because the updates on TeX Live are slow. Only stable releases of ConTeXt are synced with TeX Live, while ConTeXt users are accustomed to the almost daily beta releases of ConTeXt. (So much so that if ConTeXt is not updated for a few days, users think that something is wrong with their setup).

An alternative TeX distribution for ConTeXt is ConTeXt Minimals. Its name, and motto, should not be confused with minimalism. On the contrary, ConTeXt minimals contains everything needed to run ConTeXt (well everything except ruby, which is used by MkII scripts) and once installed, it occupies a good 200MB disk space. It is minimal in the sense that if you took away anything from it, some functionality of ConTeXt would be crippled.

Smaller is not always better

Recently, I noticed that building packages from AUR–especially big packages–started taking a long time. makepkg was spending a lot of time in compressing files. After a bit of searching, I found that thsi was because Arch Linux switched from gz to xz as a compression format.

In principle, this move is a good step. xz takes 30% less space than gz. So, while installing binary packages, you download less bits at the cost of running your cpu at a higher speed for some time. However, when it comes to building packages from AUR, xz is horrible. xz superior compression comes at the cost of a drastic increase in the compression time (see here for a realistic test case). When building a package from AUR, you spend about 10 times more time to create the binary package using makepkg, and then spend three times more time to uncompress the package using pacman. All that to save 30% of space in /tmp/ that will be deleted at the next reboot.

I did not like this trade-off, so I have decided to revert to gz for the packages that I build on my system (and also for context-minimals-git package that I maintain). If you also want to do that, edit /etc/makepkg.conf and change

 PKGEXT='.pkg.tar.xz'  

to

 PKGEXT='.pkg.tar.gz'  

If you only want to change the compression format for a particular package, add the above line in the PKGBUILD.

Finally, a usable calendar program

I have never managed to use my computer to manage my schedule. Most calendar programs are either too slow, too limited, too clunky, too ugly, or all of the above. Over the years, I have tried many (I mean many) calendar apps, but never found anything that I could continue to use consistently. The applications that came closest to what I liked were orage, which is a light calendar application for the Xfce desktop environment, and calcurse, which is a command-line based calendar application. Both had their strengths and weaknesses, but ultimately, did not fit into my work flow.

That is, until I tried remind+wyrd^[1]. Remind+wyrd is similar to calcurse; both wyrd and calcurse are curses based calendar applications. The main difference is that wyrd is just a front-end. It leaves all the processing to remind, which provides a ton of features. And I mean a ton. This is best explained by an example, copied from the remind wiki (and slightly modified to be self contained).

The 4th of July is a holiday in the U.S. However, if it falls on a Saturday, the previous Friday is a holiday. If it falls on a Sunday, the next Monday is a holiday.

We can keep track of the independence day in US by adding the following code snippet to $HOME/.reminders.

REM 4 July SCANFROM [trigger(today()-7)] SATISFY 1

IF WKDAYNUM(TRIGDATE()) == 6
	REM [TRIGGER(TRIGDATE())] MSG Independence day (actual)
	OMIT [TRIGGER(TRIGDATE()-1)] MSG Independence day (observed)
ELSE
	IF WKDAYNUM(TRIGDATE()) == 0
		REM [TRIGGER(TRIGDATE())] MSG Independence day (actual)
		OMIT [TRIGGER(TRIGDATE()+1)] MSG Independence day (observed)
	ELSE
		OMIT [TRIGGER(TRIGDATE())] MSG Independence day
	ENDIF
ENDIF

Then, we get

$ rem -s2 july 5 2010 | grep 'Independence'
2010/07/04 * * * * Independence day (actual)
2010/07/05 * * * * Independence day (observed)

Now, can your calendar program do this!. If this does not impress you, how about calculating when a blue moon (two full moons in a month) occurs. Add this to your $HOME/.reminders

FSET isGood(date) \
           monnum(moondate(2, date)) == \
                monnum(moondate(2, moondate(2, date)+1))

REM 1 SATISFY isGood(trigdate())

set blue moondate(2, moondate(2, trigdate())+1)

MSG Next blue moon is [blue]

Then, we get

$rem | grep 'blue moon'
Next blue moon is 2012-08-31

I know. How often do you need to figure out the next blue moon. But the point is that remind is text based and programmable. I will not try to explain how remind works. Others have done a far better job than I could ever do.

For an overview of remind, see the article in the Linux Journal by David Skoll, the author of remind. Another excellent introductory article is by Mike Harris in 43 Folders. For a bit of a history of remind, see David Skoll’s presentation. There is also a wiki with some more information, especially, how to integrate remind so that you see a pop-up message for reminders. For me, just adding

rem -q

in my .zshrc is sufficient.

---

[1] I thought that the name wyrd was geek-speak for weird. I was close. Wyrd is the ancestor to weird. Google for more information on wyrd.

Pacman, don’t eat my disk space

I run Arch Linux on my laptop that has a 100GB disk with a 15GB partition for /, a 15GB partition for /opt and the remaining 70GB for /home. Recently I ran out of disk space on /. First I thought that this was due to a huge browser cache (in opera, my temporary download directory is set to /tmp/opera/downloads which can get really big). Clearing up the /tmp did not help, and I went on a wild goose chase of figuring out which directory was hogging disk space. The culprit: /var/pacman/cache/pkg.

pacman, the arch package manager, keeps a cache of all packages it downloads! Over the last year or so that I have been running Arch, this directory had become huge, taking over 5GB of space. I do not want a cache of all package that I ever downloaded. I bit of hunting through the man pages revealed the right options.

pacman -Sc

which removes all the uninstalled packages from the cache. After that, /var/cache/pacman/pkg is at a bearable 2.5GB. I also learnt that if I ever need more disk space, I can run

pacman -Scc

which will remove all packages from pacman cache.

Linux error messages

Really?

The tale of two tiling WMs

I love tinkering with my system. About a year ago, I got this crazy idea of trying different window managers (WM). Until then, I had mostly used GNOME and occasionally explored KDE. Before that I was a happy Windows XP users (that means, I did not know what I WM was!). After trying XFCE and a couple of *boxes, I came across tiling window managers. The first one that I tried was wmii (actually wmii-ruby), which I found to be very nifty. At that time, I was gung-ho about ruby, and was elated to use a WM based on ruby. After a while, I found wmii-ruby to be a bit slow. The reason the wmii was slow was ruby. The bare bones wmii was amazingly fast. So, I switched to it. But wmii is that it is very poorly documented and uses an arcane language to configure (plan9!!). It is a struggle to figure out how to change anything. There are ruby, phython, and perl ports, but then you have to deal with the idiosyncrasy of the  port.

These days I am gung-ho about Haskell. What luck then that Haskell has a tiling window manager — XMonad. Whenever I feel frustrated with wmii, I check out XMonad. It is developing at an amazing pace, is well documented (well, if you know how to read Haskell documentation) and comes with an awful lot of addons called xmonad-contrib. However, everytime I try XMonad, after a while I switch back to wmii.

After repeating this process for the n-th time, I decided to write down what is wrong with XMonad.  The major inconvenience is the tags and the key bindings. In wmii, you can have as many alpha-numeric tags as you want. In XMonad, you have nine numeic tags. With alphanumeric tags, I can name the tags based on what project I have on them, and I do not need to remember it. I look at the tag name and I know which project is there. With XMonad, things are a bit different. Tags 1 and 2 are easy (mail and browser), but tags after that are a mess. What happens when I start a project on tag 3, start another on 4, and another on 5. After a week, the first project is over. I remove everything from tag 3, and reuse it. After three weeks, I need to carry the state of all my tags in my head. It is agonizing. And usually that  is the time when I switch back to wmii. I wish XMonad would implement named tags correctly. Which means, I do not have to change my config file and recompile xmoand to change the names of my tags!

My second gripe with XMonad is that its window management model does not fit my work model (rather the work model that I have gotten used to while using wmii). Most of the time, I am either writing a paper in tex, or writing code in haskell. In both cases, I have the screen split vertically. When working on a paper, I have two xterms on the left: one with vim displaying the tex file, and the other for compiling the file. On the right side,  I have three-four pdfs open (for reference), with the column in stack mode, so that I can read the title of the pdf file. The situation is similar while coding in haskell. Vim with Haskell code on one side, ghci on the other. Another xterm for compiling the code. And a couple of browser windows for checking the documentation. So, I work in a two column mode, with two main windows: the editor and the typeset pdf, or the editor and the debugger. XMonad’s philosophy is having one main window.  That is really irritating to me. There are user packages that allows you to split the screen in two columns, where I can achieve something similar to stacked mode in each column, but the key bindings are horrible (I mean, I might as well use Emacs).

I love XMonad, especially the new prompt and integration with xmobar. And I really like hacking around in Haskell to configure my WM. But, XMonad comes in the way. And after fighting with it for a while, I realize that there is nothing really wrong with wmii. And I switch back to wmii. I hope XMonad will implement proper named tags and a true two column layout sometime in the future.