345. Replacing gEdit with Kate

For some reason I can't get gEdit to auto-spellcheck as I type anymore. There's simply no option to do it. Funnily enough, my favourite editor vim does it without any issues -- but while I like vim and use it for most of my data processing, I prefer to edit e.g. html in gEdit. Habit, I suppose.

Anyway, while gEdit is great for everything else, it's given me an excuse to familiarise myself a bit more with Kate which I take is the KDE counterpart to gEdit. A counterpart that's on steroids like a lot of KDE applications (that's not necessarily a good thing -- see e.g. vim vs emacs -- but each to their own)

Another cool thing with kate is that you can run it in a vim compatibility mode. (Sure, there's also gVim for the real deal, but gVIM looks ugly on my computer and I'm a shallow person.)

1. Installation
sudo apt-get install kate

2. Associations
Edit ~/.local/share/applications/defaults.list

 text/plain=kate.desktop
 text/x-python=kate.desktop
 text/x-sql=kate.desktop
 text/html=kate.desktop
 text/dat=kate.desktop
 text/xml=kate.desktop

You can associate kate with as many formats are you want this way.

Create ~/.local/share/applications/kate.desktop

[Desktop Entry]
Name=kate
Comment=kate text editor
Exec=/usr/bin/kate
Type=Application
Categories=Office;Accessories;

Set dynamic word wrap, enable vim, override

3. Desktop
In gnome, either navigate through your menu to 'Main Menu' (under 'system tools') or, if you're running a stock gnome 3 without a menu, go to the overview mode (what you end up with when you put the mouse in the top left corner) and type in main menu.

Either way, go to accessories and tick the box next to Kate.

4. Set up kate

Start kate, go to settings, configure kate and set your defaults:

Enable vi mode

Set up automatic spell check

Activate Dynamic Word Wrap

And enjoy:

344. Compile a kernel (3.8) without using kpkg

Note: There is a much better and easier way: http://verahill.blogspot.com.au/2013/02/342-compiling-kernel-38-on-debian.html . What follows is just done for the sake of exploration.

Post begins:
It is incredibly easy to compile your own kernel on Debian using kernel-package. See e.g. http://verahill.blogspot.com.au/2013/02/342-compiling-kernel-38-on-debian.html

In the interest of learning how to compile a kernel in a more generic way which is applicable to non-debian systems (arch, red hat etc.), here's a method which doesn't rely on kpkg (kernel-package).

The downside is that this method does not produce a set of .deb files, and that you can't uninstall it using apt.

I'll be brief since most things are covered e.g. here.  I looked at this post when writing this.

sudo apt-get install build-essential ncurses-bin
mkdir ~/tmp
cd ~/tmp
wget http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.8.tar.bz2
tar xvf linux-3.8.tar.bz2
cd linux-3.8/
cat /boot/config-`uname -r`>.config
make oldconfig

Once you're done answering the questions, do

time make -j3

This takes 29 minutes (AMD Athlon II X3).

time make -j3 modules

This takes 4 minutes. Finish by running

sudo make modules_install
sudo make headers_install INSTALL_HDR_PATH=/usr/src/linux-3.8.0
sudo make install

Note that the default path for the headers is /usr/include, which doesn't play well with most programs that check for the presence of headers before installation, so use INSTALL_HDR_PATH to specify the destination (at least on debian).

make install takes care of initramfs and grub-update as well and generates

/boot/config-3.8.0
/boot/initrd.img-3.8.0
/boot/System.map-3.8.0
/boot/vmlinuz-3.8.0

And that's really it -- compiling a kernel even without kernel-packages is pretty easy. Reboot and everything should be in working order.

343. 'track changes' in LaTeX: collaborative writing

While I find latex superior to word processors in almost every single aspect, there is one thing I have to admit that MS/Libre/Open Office have over LaTeX: track changes. Since LaTeX is nothing but code you can obviously use something like git or svn to manage versions of .tex code. There are some differences though -- e.g. git would show you the diff output, but not necessarily the context of the changes, and I'm having a difficult enough time convincing people to use LaTeX without having to worry about setting up a git server as well (I can obviously cheat around it by running a local git server, downloading their file and push it to my git server etc, but then I would be the only one who'd be able to track the changes. Also, it's not elegant).

I have a student who is currently preparing a thesis, and while I've managed to give most of my feedback via the pdf annotation function in mendeley, it doesn't feel natural when it should be a simple matter of editing the .tex directly (yet in a way that leaves the student in control over whether to accept or reject the changes).

So here's an exploration of three different ways of passing comments and corrections back and forth when using LaTeX.

I'm also not the first one to ask this question. See e.g. http://tex.stackexchange.com/questions/3653/what-is-the-best-way-to-track-changes-with-non-computer-people

1. Make a pdf and annotate it
 This is a simple and straightforward method for passing comments back and forth. It is not a very convenient method for making any substantial changes though. On top of that, linux does not currently have any particularly useful program for annotating pdf files. See here: http://verahill.blogspot.com.au/2013/02/338-annotating-pdfs-in-linux-revisited.html for more information.

Quite apart from the lack of tool, I really want to emphasize that making small annotations is not a replacement for a tool that allows you to really stir up the text.

2. Using git
You can easily set up your own git server and use that for versioning. http://verahill.blogspot.com.au/2013/01/324-setting-up-private-git-server.html

You can see the version differences using a couple of methods, but gitk might be the easiest one. The downside with this is that you lose some of the context of the changes. Also, it shows you the code that was changed, the changes in the final document (e.g. formatting, figures etc.).

Still it's a pretty intuitive and easy way of tracking changes -- and in terms of versioning it is certainly the best solution. You can fork, roll back and generally have a perfect account of how the document has evolved.

git in particular makes it easy to see added code

In terms of small changes like fixing typos it is a lot more subtle though

3. latexdiff
latexdiff is an easy to use tool that's in the debian repos. Simply do

latexdiff version1.tex version2.tex > diff.tex

and then open diff.tex and compile it to see the changes.

Pleasantly suprised

4. Other solutions
there are plenty of solutions for introducing mark-up directly into the tex document, like trackchanges, changes etc. I've used them in the past but it lack elegance when doing heavier collaborative writing.

Thoughts

I can't help but think that the best solution is to combine git with latexdiff -- or even a special fork of git that uses latexdiff.

Googling shows that apparently I"m not the only one who thinks so: http://gitorious.org/git-latexdiff#more as well as http://tex.stackexchange.com/questions/1325/using-latexdiff-with-git
I haven't actually tested any of those methods yet, and it still more or less requires a common git server.