Revision as of 05:41, 22 November 2011

The Editor

When I was running windows, I would use WinEdt. Now I use kile on Kubuntu Hardy. Some people use WYSIWYGs and say they're really great, but I don't like them much. WYSIWYGs often try to be too helpful and end up screwing up the formatting. If I want to type \ar@/^/[r] (as I often do), I don't want the editor to try to be helpful. You can try a WYSIWYG and see if it works for you.

Kile completes environments for me. When I type \begin{whatever} it adds \end{whatever}; in WinEdt, you get this behavior by adding an extra curly brace: \begin{whatever}}. Other than that, it's just a regular text editor. If I'm in a pinch (I don't have my machine for some reason), I can borrow somebody else's machine and TeX in notepad.

I have a relatively big screen (15.4in), and I like to have the source on one side of the screen and the output on another. When there is a pause, I compile (you should learn the keyboard shortcut for this; for me it is Alt-2; in WinEdt, I think it's Ctrl-Shift-L) and see if everything looks right or if there is something I can fix quickly (maybe I forgot a "&" so something is aligned wrong). If you have a problem and you can't fix it quickly (e.g. a cryptic latex error), come back to it later. I like to comment out the troublesome spot so that I can still compile and keep an eye on the output (you should learn how to comment out a block of text in your editor; in my case, I select it and hit Ctrl-D; in WinEdt, I think it was Ctrl-Alt-RightArrow).

Unbelievable how well-written and ifnortmiave this was.

Diagrams

Pictures and diagrams are usually slower to type than to draw by hand. If you find yourself wasting too much time on a diagram, draw it on a piece of paper and make a comment in the text (or if you can, just describe it in the text) and come back to it later. Some people have suggested the idea of having a file with lots of templates for commutative diagrams, which I could copy and paste when I need them, but I've found that I can always produce a diagram from scratch faster than I can find it, paste it, and modify it. This will probably also be true for you (at least once you're used to it), but maybe not.

At first, you may have many of these "come back to it later" problems, but these will get less common. Once you solve a problem a couple of times in the peace of your office, you'll probably be able to handle it on the fly thereafter.

Managing your notes

If you're going to be texing class notes, use the \input command. There is no point in compiling the last ten lectures every time you want to see what you've written in the last five minutes. It's hard to comment out a huge block of text, but it's easy to comment out a few lines

\input{lecture08}
\input{lecture09}

in a master file. Your tex editor probably supports projects, so you can set it up so that when you're editing the file lecture10.tex and you hit compile, it knows that it should really compile masterfile.tex.

If you're going to post your notes on your web page, I recommend writing a script to do it for you. If you're just updating a pdf, then I guess a script isn't necessary, but if you're doing anything more than that (like updating a changelog or a last-updated stamp somewhere), it's nice to just have to run one command. I like to post tarred and gzipped source, so it makes sense for me to have a script which tars up all the necessary files, moves them to the math machines (where my web page is), untars them there, and compiles. Here are the (nicely commented) scripts I used to update my homological algebra notes when I was taking them: update.sh was kept on my maching in the directory where the notes were (it's what I would run to do all the updating), and mathupdate.sh was kept on the math servers in the directory where the notes were (it was executed by update.sh).

@@ Line 7: / Line 7: @@
 I have a relatively big screen (15.4in), and I like to have the source on one side of the screen and the output on another. When there is a pause, I compile (you should learn the keyboard shortcut for this; for me it is Alt-2; in WinEdt, I think it's Ctrl-Shift-L) and see if everything looks right or if there is something I can fix quickly (maybe I forgot a "&" so something is aligned wrong). If you have a problem and you can't fix it quickly (e.g. a cryptic latex error), come back to it later. I like to comment out the troublesome spot so that I can still compile and keep an eye on the output (you should learn how to comment out a block of text in your editor; in my case, I select it and hit Ctrl-D; in WinEdt, I think it was Ctrl-Alt-RightArrow).
-=TeXing fast=
+Unbelievable how well-written and ifnortmiave this was.
-You'll find that you can type faster than you can write by hand (it's faster to strike a key than to write a letter), so plain text will be fast to tex (faster than the lecturer writes it). You'll also be able to catch things that the lecturer says but doesn't write down.
-Things with a lot of math symbols are harder because you have to hit many keys to produce a symbol, so it is important to tune your macros to the lecture. If you're going to be doing a lot of algebraic geometry, you'll want to write <code>$\O$</code> instead of <code>$\mathscr{O}$</code>. Some people would rather have it be <code>$\calO$</code> or <code>$\cO$</code>, but I don't agree; if I have another context where the most common capital O is <code>$\mathbf{O}$</code>, then I'd use <code>$\O$</code> for that too. If you have a lecture where both kinds of capital O occur, then I think it makes sense to have <code>$\calO$</code> and <code>$\bfO$</code> (or something to that effect), but if there is only one kind of O that shows up, you may as well make it <code>$\O$</code>.
-Your macros should have some rhyme to them. Some examples:
-* I always use doubled letters for blackboard bold, so the integers are <code>$\ZZ$</code>, the reals are <code>$\RR$</code>, and if I had a little blackboard bold k, it would be <code>$\kk$</code>.
-* For roman font operators, I use lowercase macros, so Hom is <code>$\hom$</code> and Tor is <code>$\tor$</code>. The commands <code>$\Hom$</code> and <code>$\Tor$</code> would be reserved for sheafy or internal Hom and Tor. I guess I probably started doing this because it's easier to type a lowercase character.
-If you don't know how to produce a symbol, make a note of it and come back to it after the lecture. If a symbol starts showing up a lot and I don't have a macro for it, I'll usually make one (e.g. <code>\def\J{\mathfrak{J}}</code>) and add it to my macro list later. If I don't know how to produce a <code>$\mathfrak{J}$</code> and it starts coming up a lot, then I would do <code>\def\J{J}</code>, then use <code>$\J$</code> whenever I want a fraktur J and then change the definition later (rather than change every instance later).
-In addition to choosing good macros, it's good to learn where you can drop braces to make the typing more managable. TeX read one token at a time (where a token is a character or a command). If something is just one token, you don't need braces around it. For example, instead of writing <code>$x^{\alpha}$</code>, you can write <code>$x^\alpha$</code>, but <code>$x^{\alpha_i}$</code> produces different results than <code>$x^\alpha_i$</code> (because <code>$\alpha_i$</code> is more than one token). Another example: instead of writing <code>$\frac{\alpha}{\delta}$</code> you can write <code>$\frac\alpha\delta$</code>. In fact, you can even write <code>$x^\frac 12$</code> to get <code>$x^{\frac{1}{2}}$</code> (because TeX will read the arguments of \frac before it decides what to do with the superscript), but even I think that's a little much; I'd probably write <code>$x^{\frac 12}$</code>.
 =Diagrams=