When I decide something needs to be added to my workflow, it is easy to add. The difference is whether your tool drives your workflow or you workflow drives your tool.
The Java world is a great example of tool-driving-workflow. IDEs are massive, and you are generally constrained to a code-build process as thought out by the vendor. Generally speaking, the tools have good "average" efficiency. Anybody who has used the tool could sit in front of anybody else's and be as efficient.
Emacs is obviously the other end. My workflow influences the tool in so many ways that it would be nearly impossible for somebody to sit in front of my Emacs and use it efficiently. However, I am far more efficient than within any IDE, because I have bent the tool to my will.
Something like Sublime doesn't necessarily prohibit you from building a workflow and tools around it. It would just have include the command line as the programmable part.
EDIT: Specifics. A simple example: I was editing a bunch of wiki pages, do a combination of creating, formatting and moving content. I built a small set of tools to handle the repetitive parts. It is the aggregation of all the small things like this that makes the tool so much more valuable.
I understand that customizing can improve productivity. What I haven't seen is someone name a particular task, and show how much easier it is to customize in their favorite editor vs emacs/vim/sublime/editor of the day. Sort of like a benchmarksgame.alioth.debian.org or rosettacode.org but for editors.
I'm not sure how that would work, because the very nature of the beast is exceedingly personal. As I mentioned in the example I added to my original comment, it is about small things that, cumulatively, add up to big things.
I think the kinds of things that would show up on a rosettacode-type site are most likely already exposed in terms of plugins of some sort (however the editor defines "plugin"). It is the murky area between keyboard macros and plugins that the programmable editor makes its mark, and those things are highly individualized.
It would be fun to have something like seewhatididinmyeditor.com, that just let you post snippets of these kinds of things in your editor's native tongue.
Here's another example: I was converting some javascript to coffeescript. Coffeeescript's conventions are snake_case, and I wanted to follow those conventions, so I added this little thing:
(defun my-uncamelize (s &optional sep start)
"Convert CamelCase string S to lower case with word separator SEP.
Default for SEP is an underscore \"_\".
If third argument START is non-nil, convert words after that
index in STRING."
(let ((case-fold-search nil))
(while (string-match "[A-Z]" s (or start 1))
(setq s (replace-match (concat (or sep "_")
(downcase (match-string 0 s)))
t nil s)))
(downcase s)))
Now, I didn't write it; I grabbed it as a snippet somebody else had written and shared. Now, with a bound key, I had a single key-stroke that would snake-case an identifier.
Again, not a big deal, but it made the workflow for converting those js files just that much easier.
Here’s an example of powerful customization. I recently wrote a macro in Vim that, when run in a particular Visual Basic file, would search for a certain part of the file with an SQL string, delete everything in the file but the SQL string (just temporarily), and reformat the SQL string for easy viewing. I needed a macro because that Visual Basic file was compiled from another source, so it kept getting rebuilt to the full version but with different SQL, and I had to keep on using my macro to view the new SQL.
The main reason this was easier in Vim than it would be in Sublime Text is that I could edit the macro after the fact – the macro was just text. All macros are stored in a register, and registers are basically like multiple clipboards, so to edit the macro, I just had to paste the contents, change the text, and copy it back to the same register. Because of that, I could develop the macro bit by bit. At first, I just made the macro delete the parts of the file other than the string with SQL. Then, when I realized that I was going to be viewing the SQL in this file many more times, I edited the macro’s register. I was able to develop the macro bit by bit. And I could even save the macro in a text file for me to load later. Basically, I used Vim macros as a substitute for a scripting language – Vim has convenient text-manipulation functions built-in, and text manipulation and viewing were my goals.
Another way Vim made writing the macro easier is that it has more powerful macro primitives. It is easier to, for instance, select all the text in the next quoted string on this line, because Vim’s text-manipulation primitives are more granular. I think Sublime Text can select the cursor’s current “block”, but not a double-quoted string specifically.
Here’s the final macro (^M carriage return characters were turned into actual newlines, and ^[ and ^V characters are invisible):
/History Section goes here
f"vi":s/\( \+\)\( \+\)/\r\2/g
gv--dgg/\.replace(
hhi
--
dG:setf sql
gg/"Select
a
-V-I--
.
I can give a few, but I also think it's something that needs to be experienced to really "get it".
At work I have to use a proprietary version control and build system (don't ask), and it was relatively easy to hook it into Emacs.
We also have an internal website with a cross referenced, hyperlinked version of the code. I have a function to launch a browser and go to the cross reference site for the symbol under the cursor.
One of our coding conventions is that the .h file for a class named ClassName is ClassName.h. When I use a class I haven't used before, I have a keyboard shortcut to add the #include for me. If I miss one, the compile error jumps right to the class name and I use the keyboard shortcut - it takes about 2 seconds.
I have a function that will take whatever text I've highlighted and launch a web browser doing a search in DuckDuckGo for that text.
I have a function to run the selected text through Python and replace the selection with the result. If I type 4+5 I can select it, press Ctrl + Alt + P and it gets replaced with 9.
By default Emacs opens *.h files in C mode. I have a function that checks whether there's more .cpp files or .c files in the same directory and sets C++ or C mode appropriately. I replaced the default behavior with my version, so it happens automatically.
I could go on all day.
Having a fully programmable editor means that if I ever find myself doing the same thing more than a few times, I can automate it. It means that if I don't like the way Emacs does something I can change it. Customization in most other editors is limited by the editor's plugin API. There's no such limitation in Emacs.
In the end, personal taste is what counts. All of these you mentioned can be done in Sublime Text as well.
I used emacs for 2 years, than switched to Sublime Text 2. All of the shortcuts I use is available via emacs package, and due to it's extensive API, I can add the functionality I want, with python, my favourite language.
Emacs is much more extensible than Sublime Text for sure. On the other hand, Sublime Text's extensibility is enough for my needs.
The Java world is a great example of tool-driving-workflow. IDEs are massive, and you are generally constrained to a code-build process as thought out by the vendor. Generally speaking, the tools have good "average" efficiency. Anybody who has used the tool could sit in front of anybody else's and be as efficient.
Emacs is obviously the other end. My workflow influences the tool in so many ways that it would be nearly impossible for somebody to sit in front of my Emacs and use it efficiently. However, I am far more efficient than within any IDE, because I have bent the tool to my will.
Something like Sublime doesn't necessarily prohibit you from building a workflow and tools around it. It would just have include the command line as the programmable part.
EDIT: Specifics. A simple example: I was editing a bunch of wiki pages, do a combination of creating, formatting and moving content. I built a small set of tools to handle the repetitive parts. It is the aggregation of all the small things like this that makes the tool so much more valuable.