adiM

> I made a few abortive switches to Vim that didn't last a week because my productivity was too hampered and the environment too extreme & foreign.

I started vim by using cream[1], which behaves like a normal editor with menus to configure everything. Once you get used to the different concepts, you can start editing the `.creamrc` file. After a few years, I was comfortable enough to drop cream completely and use hand written vimrc file for the configuration that I liked.

[1]: http://cream.sourceforge.net/

One can use Python, Lua, Ruby, and a bunch of other programming languages to write VIM scripts. At least on ArchLinux, the vim binary comes with support enabled for these scripting languages.

I use zsh and for this use case I typically use "mkdir foo" followed by "cd $!".

Would you care to elaborate why you have curly apostrophes and em-dashes?

Could you please add an example to show how to export graphs to SVG, EPS, PDF, etc. (Sorry if the example is included in the documentation, but I could not find it).

Any plans to add support for Julia as well. One of the things holding Julia back is a good plotting library.

With LuaTeX (the modern version of TeX), such catcode trickery is not needed. LuaTeX provides a hook into the file reader, and you can simply change transform the input as you read it. For an example in ConTeXt, see this answer on Tex.sx: http://tex.stackexchange.com/a/4174/323

If you are interested in academic articles, why not search on google scholar? It provides much more relevant results.

Umm.. vim works fine on all platforms.

The syntax for optional argument and the lack of support of named parameters are limitations of LaTeX, not TeX. For example, see ConTeXt, which is a macro package on top of TeX, that has much more consistent syntax and all macros accept named arguments.

I guess this is a difference in philosophy. I prefer to use a te t editor for editing all types of text: code, emails, tex markup, HTML markup, etc. Hence, for me, a text editor is better than a word processor. But I do like the convenience of not having to go back and forth between a previewer (PDF reader) and the text editor, and therefore like the fact that emacs allows embedding of imaging. (Not to mention the fact that none of the word processors can beat TeX output in terms of quality and flexibility)

Images are useful if you are authoring a math heavy document (and don't want to go back and forth between a previewer and the editor).

See http://www.gnu.org/software/auctex/img/preview-screenshot.pn... for an example.

One part where emacs beats vim is the ability to embed images. Emacs + AucTeX is by far the best editing platform for LaTeX because auctex converts the math snippets into images and displays them in emacs buffer. It is possible to write the backend support in vim as well, but not possible to display the image inside the vim buffer.

> first with the advent of email “conversation” threads

Google did not invent email conversations. Most email clients worth their salt could sort email based on thread since at least 1999/2000 (and also before that I only started using computers around that time).

Indians started cultivating rice (~ 2000 B.C.) much later than the Chinese (~ 4000 B.C.) [1]. Given the rate at which lactose tolerance spread in Europe, Indians had already developed lactose tolerance by the time they started cultivating rice.

[1]: http://sourcing.indiamart.com/agriculture/articles/origin-an...

Certainly not all of Asia. In India, from anecdotal evidence, almost all adults are lactose tolerant.

I always use a local IMAP client (alpine), so am not really bothered by fastmail's rather basic UI.

IMAP has tags (rather keywords), that you can assign to multiple posts. Just because you assign a keyword to an email, doesn't mean that it should be moved to a new folder. Gmail does that, and therefore breaks IMAP.

Darn, for a moment I thought that this was a site that encourages people to write with a real pen: fall back in love (PenFM).

Gmail's IMAP implementation is really buggy. No distinction between tags and folders, non sorting done at the server level, etc. Frustrated, I also moved to fastmail two years ago; it is slightly expensive, but is standard's compliant and works flawlessly.

I was waiting for a Java solution with an AbstractFactory somewhere.

How does this compare to existing text formats that generate multiple outputs, in particular pandoc (which supports an extended version of Markdown)?

I use alpine and have set w3m as the HTML reader in my mailcap file. w3m also displays images in HTML. Alpine is able to display most HTML emails just fine, but when it fails, I simply press V (which shows different mime parts of the message) and Enter (by default the focus is on the 2nd part, which is text/html; Enter launches the default html browser, which is w3m that displays the message). This gives all the benefits of alpine, with the option to display html+images in the same terminal if I need to.

I have been using Alpine/Pine for almost 13 years, and agree with most of your concerns. However, some of these can be controlled using the settings.

- Full name search in LDAP work correctly. Have you set name, surname, and given name attributes correctly in your LDAP setup.

- I exclusively used IMAP and have had no troubles with IMAP folder being fist in the list.

- Starting in the inbox (using key sequences) has always worked for me.

- Reply all does not include me in the Cc. Have you tried setting up alternate addresses field in the settings.

For HTML emails, I have set w3m as my html viewer. w3m works better with complex layouts in html.

Isn't this copied from Haskell? Being a lazy language, Haskell has the advantage that the underscored variable is not even evaluated.

Well, vim cannot syntax highlight markdown. Period.

There are multiple markdown syntax highlighting plugins, but none of them work most non-trivial markdown features (a paragraph indented by four spaces after a list item is a regular paragraph not a code block; extend the same analogy to multiple nested lists...).

How does it compare with Opera Mini browser?

That still leaves around 60 unique binaries.

<pre> find /usr/lib/git-core -type f -exec md5sum {} \; | cut -d' ' -f 1 | sort | uniq | wc -l 68 </pre>

Comparing from TeX: <pre> pacman -Ql texlive-bin | grep '/usr/bin' | cut -d' ' -f 2 | xargs md5sum | cut -d' ' -f 1 | sort | uniq | wc -l 181 </pre>

Please verify your facts before bashing TeX.

Firstly, tab completion does not need those binaries. Zsh does similar tab completion for git (which uses 150 binaries) and hg (which uses one binary).

Now for TeX, pdfTeX has been around since, well, since the mid 90s. It has been part of the standard TeX distribution for more than 10 years. So for the last 10-15 years, TeX can directly produce PDF.

Similarly, xetex has been around since 2003-04 and luatex since 2007-08. With both of them, using OTF and TTF fonts is as simple as just saying `\setmainfont[Dejavu]` (using the simplefont module in ConTeXt or fontspec package in LaTeX). No need for converting to TFM files or anything.

The reason TeX is built like TeX is because when it started, postscript/pdf did not exist, Type1/TrueType/OpenType fonts did not exist, so TeX had to create its own formats. Over the years TeX has adapted to the new technology: you can easily use UTF-8 input (for text and math), ttf/otf fonts, opentype math fonts, use Lua to write macros, and get PDF output. You are objecting to the fact that TeX works hard to be backward compatible and carries around all the legacy programs so that documents written in 90s still compile easily today. If you don't want them, just don't install them (again this is more of a packing issue than anything else).

So you would prefer one monolithic binary over a collection of binaries each of which does a specific task (bibtex for biographies, xindy for indexing, dvips for converting dvi to ps, etc.). For comparison, the git installation on my computer contains some 160 binaries (hidden in a directory different than /usr/bin). Should git be rewritten in a leaner way as well?

Most of the size of a TeX distribution is due to the fonts and the documentation. I did not analyze TeX Live distribution due to its size, but ConTeXt standalone (which is a distribution just containing files needed for context), is around 230MB, out of which 100MB is fonts, 45MB is binaries, 42MB are core macro files, and 26MB is third party modules (and their documentation). You will get similar numbers if you install only the LaTeX packages that you need. Blame your distro's packagers for forcing you to install a single monolithic 3GB package.