| > 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/ |