[TeMPOraL]

If you're working with something else than C#, Java or the like (i.e. languages that benefit hugely from features offered by IDEs (or that require IDEs to write in them and stay sane - if you're not feeling charitable)), then yes - benefits of speed, flexibility and efficiency. That's without even bringing up the topic of org-mode... :).

[iamcreasy]

Can you give me some example of efficiency? I've always thought IDEs are more efficient, i.e. intellij IDEA indexes everything and provides superior auto-completion.

[to3m]

For your ordinary average everyday normal well-supported language, stick with the IDE.

But suppose you're working with some random language that nobody's ever heard of. It's some tool-, product- or site-specific thing. If you're very lucky, there's some ropey Scintilla-based text edit widget that lets you work with one file at a time. If you're not, there's quite literally fuck all. When you search on Google, there's 0 useful results (until you get to page 9, and there's 1 single post from somebody, on some random forum for general blarney, ranting about how they're doing some contract work and using this stupid language and it's terrible because there's no tools and they're stuck using notepad and their life sucks).

If you've got an IDE, now you're sort of stuck. Maybe you can find a language it supports that's a bit like, and then you've got syntax highlighting - sort of - and autoindent - maybe. But you have to do code browsing by grep, effectively, and you've got 0 in the way of code completion.

With emacs on the other hand you can relatively easily code up some language-specific support for syntax highlighting (takes 5 minutes) and autoindent (5 minutes for something basic, maybe 1-2 hours if you want to get fancy). Add some imenu regexps (5 minutes) and you've got code browsing from within a file. Put your imenu regexps into Exuberant Ctags (15 minutes), and you've got cross-file code browsing. Code completion... well... yeah... it's not perfect, but if you squint a bit, dabbrev (2 minutes if you need to tweak your syntax categories) is fine.

I've never failed to turn a time/effort/hassle profit from doing this.

[TeMPOraL]

Too much clicking in the IDE, though I guess this complaint goes more towards Eclipse than IDEA :).

But Emacs (and Vim) offer you superior text editing, if you can be bothered to learn it. Semantic navigation, convenient incremental search, semantic editing, keyboard macros, etc. etd. - you can do much more in fewer keystrokes, which is important in keeping yourself in the flow. In Emacs, you get all the benefits of highly optimized keyboard navigation and editing for every task you'd like to do - writing code, managing files, inserting simple and complex code templates, managing projects, complex work with Git repositories, etc. - and it's all consistent - you can do the same regex incremental search in e.g. your commit logs as you do in your source files.

My overall personal impression about Emacs is that it's the most efficient environment optimized for anything text-related out there (especially if you switch to vim keybindings for text editing and navigation, which are arguably smarter).

[jeena]

I'm using emacs for a year now but I'm reallt bad at it, I wish there was a text like your comment with the words linked to specific webpages or videos which explain how to install everything you need for that word and show how to use it. I would link:

"Semantic navigation", "incremental search", "semantic editing", "keyboard macros", "optimized keyboard navigation", "inserting simple and complex code templates", "managing projects", "complex work with Git repositories", "regex incremental search"

[johanvts]

Something I learned way to late was to use the build in features for learning about functions and variables.

C-h f : find help for functions C-h v : find help for variables C-h k : Get help for a key-combination

If you have helm mode installed it's often very easy to find the functions you are looking for.

[rkangel]

You're probably right about the autocompletion. I've never been able to get it to work particularly well in emacs (although I'm probably due another attempt). If you're focused on a particular target with a good IDE (i.e. Visual Studio, something by IntelliJ and probably nothing else) then they can be a good tool to use.

Among other things, I'm current developing some code for an Atmel chip. The environment for this is Atmel Studio (VisualStudio based), which has excellent Intellisense based autocomplete/navigation etc.. The thing is, I keep finding myself using emacs. Apart from the obvious 'force of habit' reasons for this, I think there are two factors:

1) Even with the autocomplete I still code faster in emacs. The various features like being able to load up multiple files at once on split windows, better facilities for swapping code around (I could go on) mean that it just goes faster. I still use the IDE for bits and pieces - it's particularly convenient for when I'm using unfamiliar parts ofthe hardware libraries - but I keep going back to emacs.

2) Developing for the Atmel is only ONE of the devices I'm targeting at the moment. I've got another ARM device (using Keil), a whole host of Python bits and pieces, a Windows GUI app. Being able to write the code for all of these in one place is unmatchable. Particularly as they interrelate and share code. It even helps the style look the same (where appropriate). A well configured emacs gives you a great development environment for anything.

[e12e]

> indexes everything

So should your text editor (and/or it's companion programs)

> and provides superior auto-completion.

See above. Superior is a bold claim, superior out of the box for "strongly" supported languages, perhaps? (Eg: one way of working with java in vim is to use eclipse for extracting some information about a project[1])

Personally I'm more familiar with vim, than with Emacs -- arguably the main difference is that Emacs has one standard and sane scripting language (lisp), while vim doesn't (I'm very happy a lot of masochists work tirelessly to provide vim plugins for everything I need (and a great deal I don't) -- but I think it's hard to argue that vimscript is a "good" language. And having other bindings (eg: ruby, python) is a bit of a mixed blessing)).

But what they have in common, is a strong focus on making it easy to automate transformation of text. Any kind of text. With any kind of automation, via commands. As such they empower a continued process of improving the process of writing and editing.

I like Moolenaar's (vim's creator) short text and expanded talk on 7 habits of effective text editing:

"7 Habits For Effective Text Editing 2.0": https://www.youtube.com/watch?v=p6K4iIMlouI

"Seven habits of effective text editing": http://www.moolenaar.net/habits.html

I often feel that modern IDEs with typical "modern" languages, tend to trap you in a certain way of working that is "with" the IDE, that tend to be counter-productive if that "one true (editing) process" doesn't fit. And they tend to provide only something like 70% of the benefit of a true IDE, like a Smalltalk System coupled with a Object Database, or something simpler like a complete Forth system.

For better or worse, all current popular programming systems (that I'm aware of) has the hopeless abstraction of program text organized in file system files in folders (often coupled with half-integrated resource files, be they xml-layout, binary images, fonts or other stuff).

So no IDE can be effective, because the central abstraction remains only half-structured text, and you can only get that far with strapping semantic analysis on top. So as long as you're (forced to) working with text, programs that enable text editing and transformation will have an edge.

I don't think there's a wall between the two: you might want to use something like [1], or vim-mode in IDEA or something -- but if you want one effective tool to work with: Documentation, a handful of mark-up languages, a data language (like SQL), and a handful of programming languages (eg: assembler, C/C++, python), patch-files and perhaps writing email -- then I think text editors are going to be a good investment.

I do think that text editors (for writing code) is a kind of local maxima - but if we want to stick with traditional files and file systems (probably a terrible idea), they do help facilitate tools that have somewhat loose coupling (between editing, debugging, high-lighting, re-factoring, formatting) and I think that helps keep systems portable (you can take a similar set of C++ files and preform a similar set of transformation (with completely different tools) on Linux and Windows and end up with (different) binaries that preform a similar function.

Another great video that I think demonstrates text editing as different from "just" an IDE, is Russ Cox' short intro on ACME:

"A Tour of the Acme Editor": https://www.youtube.com/watch?v=dP1xVpMPn8M

In short, I suppose text editors are a superior user interface for interacting with text-like structures in general. The relative benefit for programmers depends a bit on what kind of system you work with: I'd prefer a simple, less verbose language, like Kotlin coupled with a plain editor, to an IDE coupled with more traditional Java (esp: Java 5) -- I firmly believe auto-generated code is a dark pattern: if it can be automated, it should be moved to a run-time or a library so that it can be maintained in one place, rather than leaving dead and possible buggy code in dark corners of a large code-base.

[1] http://eclim.org/