Anyone seriously considering Emacs for LaTeX editing should also take a look at the yasnippet package. The customizable autocompletion shortcuts make it really easy to insert commands using just keywords. In my case this has proved to be very helpful especially when inserting figures or inline equations. I can create a snippet so that when I type fig+<tab> it inserts a \begin{figure}.. \end{figure}float and positions the cursor at the proper field saving me a lot of keystrokes.
AUCTeX has the LaTeX-environment function (C-c C-e by default) that does even better than that (inserts the figure environment, offers to center, creates a label, a caption, etc.), and also handles all environments, plus there's no need to create the snippets.
I just used figure as an example. If there's no predefined keystroke or function available such as in the case of LaTeX macros that you tend to use frequently, snippets can be of use. Of course one can do without them, but they're definitely worth considering if you use emacs regularly.
I've stopped using yasnippet because I find it too resource-intensive. It's especially noticeable on emacs-startup, even of good machines, and I've found myself not using it very often. So I decided that it wasn't worth the time.
My main gripe with yasnippet is that its feature list is pretty lackluster compared to some advanced vim snippet plugins like xptemplate.[1]
xptemplate has a bazillion features, and yasnippet is primitive in comparison. Just a simple example is that in xptemplate (and probably any respectable snippet plugin in vim) you can type a part of a snippet name, hit TAB, and it will expand the snippet whose partial name you typed (assuming there's no exact match). In yasnippet, you have to type out the full snippet name before it can be expanded. This is pretty annoying, especially for long snippet names.
There are tons of other examples of far more advanced functionality, such as a variety of snippet repetition and embedding features.
This comparative lack of features in yasnippet is pretty surprising, because emacs extensions are usually very feature rich, and everyone seems to love yasnippet. But I think that's because most emacs users don't know what they're missing.
And before someone says it, yes, I know yasnippet gives you the ability to embed eLisp code in it, so I could potentially write all the functionality I need myself. But that's really beside the point. I'm talking about built-in features, not the ability to code up the features myself.
> Just a simple example is that in xptemplate (and probably any respectable snippet plugin in vim) you can type a part of a snippet name, hit TAB, and it will expand the snippet whose partial name you typed (assuming there's no exact match). In yasnippet, you have to type out the full snippet name before it can be expanded. This is pretty annoying, especially for long snippet names.
I was hoping someone would say that was possible. Thanks, I'll play around with the available yas-prompt-functions.
As for SRecode, that looks interesting but its documentation is impenetrable. Someone seriously needs to write a bunch of tutorials for that thing. Otherwise, I can't really tell if it can do what xptemplate is capable of or not.
I found some comments from SRecode's author suggesting that it's intended for different uses from yasnippet:
"Thus, the audience for yasnippet and SRecode is quite different.
Of course you could do yasnippet like things with SRecode if someone
took the time to improve the field-editing feature in SRecode, but
that has not been my focus."[1]
I agree Srecode needs to improve its documentation. It took me a while to learn to use it by reading the actual templates written that come with CEDET. I may write a tutorial for it at some point. But not now.
I never really investigated why, I think it's because I use melpa as my main package repository, but yasnippet loads lazily now. This is assuming the 'old' package didn't have this set up by default.
Sure Auctex does provides kb-shortcuts. But rather than using predefined keystrokes, I prefer to use my own. Besides, snippets can be used for commands/environments for which AucTex provides no shortcut or for things such as macros.
I hate the best editor debate because I think it's distracting from what's more important — what both editors can learn from each other and what both need to do to improve. I used Emacs for years, switched to Vim because of RSI, then recently switched back to emacs+evil. Frankly, for what I do most (R, R+knitr, C++ with clang autocomplete), no single editor is great. First, there's too little ability to switch between modes within a single buffer in both Vim and Emacs. The feature's entirely lacking in Vim AFAIK, and poly-mode in R uses a high level hack that (1) doesn't play well with other modes (including evil) and (2) has so thoroughly destroyed my documents in the past I refuse to use it now (mostly because it uses many buffers behind the scenes, which destroys undo history).
In general, if you want flawless R support in certain blocks of text (as in a .Rnw file) in between LaTeX blocks that are fully connected to AucTeX, well... you're out of luck. And Vim... Vim-R-Plugin is useful, but it's sort of a painful hack to use tmux just to get R and Vim to talk (and I'm saying this even though I love Tmux).
Vim has YouCompleteMe, which is smooth as silk compared to Emac's options (which are painful and poorly integrated, especially with clang). But some lower-level issue in Vim causes this constant error message in Vim whenever YouCompleteMe uses clang — bloody annoying. So overall, both editors have huge issues that would require serious overhauls or tedious bug fixing in various modes. Sure, Emacs does AucTeX better, but until it does everything better (or Vim does everything better) it's a flawed editor. Both are flawed editors. But sadly everyone thinks the best course of action is to start fresh — which usually creates a feature-poor flawed editor on a new shiny foundation, that fails to attract developers because it's feature poor. (apologies for ranting -- jetlag).
Code (live code) + LaTeX can be done with org-babel (kind of,) and I use mmm-mode (sorry, not on my computer now and don't remember the precise name, but it's on Melpa) and for multiple major modes in different blocks, works nicely (but don't know a way to keep the defined modes per section across sessions/file closes)
Neovim has a good chance to become the best editor. They are taking a really hard stance against all the cruft in Vim and have some really great features already implemented. I'm especially excited about their goal of reimplementing all IO with libuv. The lack of proper asynchronous IO has been a sore point in vim and emacs for a long, long time.
Perry Metzger talks a bit about the problems of emacs blocking starting at the 34'39" mark in his "The Editor of a Lifetime" talk[1] for the NYC Emacs Meetup. Not that his points are new, but this is just one of the first things that sprang to mind when I heard your "it works fine" claim. Here are some excerpts:
"Threading. This has been an irritant for me for years. Emacs
blocks all windows when you're doing computation in any window.
It's an operating system, but not enough of an operating system.
I myself will run three instances of Emacs to get around this.
I'm slurping in my email and I can't do something at the same time
because it's off in space slurping in my email. It's going off and
doing some extended computation and I can't go in another window and
do anything else at the same time. ... If it's doing extended
computation and a lot of file IO and talking to the network, it
blocks you. There's not more than one thread there."
There's also this[2] discussion of lack of threading in Emacs on the Emacs Wiki.
It has support for AIO, as had vim for quite a while, but it's not pervasive in the standard library and the ecosystem. Both editors have way too many plugins that block the UI needlessly while you're typing (autocompletion, syntax checking etc).
It's quite more popular than you think. `M-x term` is an example. It's a full-blown terminal emulator in Emacs that runs entirely in another process. Here is another example of async grep/ack/ag: http://tuhdo.github.io/helm-projectile.html#sec-9 . As you can see, Emacs gets line by line results from grep/ack/ag without blocking and gives you new results and you type.
Or Emacs's fantastic support for communicating with REPLs in many interpreted languages.
What's wrong with Company: http://company-mode.github.io/? It can give me a large amount of completion candidates without any issue. It's also smooth. Maybe you are using auto-complete?
I'm seeing a lot of "X is best" or "y additional feature is powerful".
Neither adds much to the discussion.
Which isn't to say that posts such as this can't provide value. I've been using vim and its antecedents for over a quarter century, as well as well over another editors and authoring tools (closer to two dozen). Including a few forays into emacs-land.
I find discussions of tools useful, and have added a few to my own suite in the past year. Most recently vim-outliner, an outlining plug-in for vim, also Pandoc, and in the past two years, for the first time after considering it for a long time, LaTeX.
Describing WHY an editor or tool suits you, or SPECIFIC features it has or offers, is far more useful.
It will also make the discussion here hugely more valuable than just pointing people at vim or emacs (again). Both are pretty easy to find without that help.
Providing reasons and specific benefits -- much more valuable.
I switched to vim years ago for everything else, but I still use emacs specifically for auctex. I have yet to find a vim equivalent nearly as convenient. In particular, C-c C-c as a do what I mean compiler (checking timestamps to figure out whether to run LaTeX, BibTeX, etc, as well as C-c C-e to insert an environment, and alt-enter to insert a newline and \item.
Have you tried looking at VIM-LaTeX (http://vim-latex.sourceforge.net)? It does exactly what you described and is just as customisable as auctex.
For example: <leader>ll will compile your document, multiple times if necessary, and show you warnings/errors in a new window, letting you hit enter on each to jump to the line. Lots of helpers for inserting environments, items, packages, too!
But if you're used Emacs just for auctex, more power to you for harnessing the power of two awesome editors!
I don't find snippets nearly as convenient as the built-in auctex keybindings. C-c C-e itemize <enter> item1 <alt-enter> item2 gives me (properly indented for surrounding context):
I could probably convince vim to do that, but auctex does it out of the box with no additional configuration required.
Likewise, I could probably set makeprg to latexmk or rubber or some other DWIM script, but that ought to Just Work as easily as auctex's C-c C-c, and shouldn't require a pile of configuration.
I haven't even found a way to bind <A-Enter> in vim's insert mode, because vim can't distinguish that from <Esc><Enter>.
results in exactly the same thing. True, I had to spend 5 minutes writing a snippet to do that,[1] but that was because the default snippet behaved differently (though arguably just as intuitevely).
xptemplate comes with a bunch of LaTeX snippets (and ones for about 50 other languages), but it's easy enough to add more yourself, especially when the desired behavior is as simple as you describe. It gets trickier when you have lots of nested snippets, menus, conditionals, etc. But the tools are there as features, and you don't have to write the features themselves yourself, just use them.
As for latexmk, depending on how complex your needs are, you may not have to configure it, just run it. A "latexmk -pdf foo.tex" will probably do what you want. Configuring it or using other/more options give you more control, which is a good thing. AucTeX, by the way, has a latexmk plugin.
[1] - It would have gone a lot faster had it not been a couple of years since I wrote an xptemplate snippet.
> While on the subject of configuration, if you are not a fan of configuring your editor, I'm not sure I understand what you're doing using Emacs.
I don't mind configuring something when I actually want to change its behavior, but I'm a big fan of sensible and helpful defaults that Just Work. I'm not complaining that there isn't a vim mode that works exactly like auctex out-of-the-box; I'm annoyed that there doesn't seem to be one that has equivalent functionality out-of-the-box. I could reinvent it using templates/snippets, but I didn't have to do so with auctex.
> As for latexmk, depending on how complex your needs are, you may not have to configure it, just run it. A "latexmk -pdf foo.tex" will probably do what you want.
I understand that I wouldn't have to configure latexmk (or rubber, or any number of other DWIM scripts for LaTeX), but I'd still need to configure vim to use one of them and have a convenient keybinding for them. I'd also prefer not to rely on an external script; I'd rather have something built into vim and configurable within vim.
Navigation and label handling. M-j lets you jump to a section, C-( inserts a uniquely numbered \lab and C-) gives a menu for inserting a \ref to an existing label.
(These may not be standard bindings - my .emacs is a horrible mess of legacy code dating back to a pre-git world.)
Try out TexStudio (http://texstudio.sourceforge.net/). Free, open source, integrates with MikTex, ctrl-space autocompletion for bibtex entries, can easily switch build chain from latex-dvi-ps-pdf to xelatex-pdf or pdflatex or latex-dvipdf.
There's Lyx, though I've long found it harder to deal with than straight-up LaTeX.
If you're doing quick small documents, Markdown and Pandoc may well be a better fix for you.
A useful mode for working with LaTeX (or other tagged documents) is to have a build system which watches your source, re-builds it as you edit it, and a viewer which updates as the generated PDF is refreshed.
You can do this with LaTeX, Markdown + Pandoc, or numerous other systems. It's quite powerful.
