[SoftwareMaven]

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.

[mrgoldenbrown]

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.

[SoftwareMaven]

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.

[roryokane]

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

.