That's why I use Evil (http://emacswiki.org/emacs/Evil). I get all the programmability benefits of Emacs with the more powerful editing model of Vim. In fact, the whole of Evil is actually greater than the sum of its parts, since it provides a high level interface for extending the Vim editing model itself in Emacs Lisp. Creating new text objects, for example, becomes trivial.
So what kind of stuff do you program inside of it? What kinds of problems do you solve?
I mean, I've never really felt the need to program an add-on to text editor. I download syntax highlighting packages, and there are common macros like "remove trailing whitespace" already installed. Keyboard shortcuts can be changed in lots of editors and OS's. In the past, I've definitely been upset that a particular editor didn't support a particular feature, but by now they've progressed enough that I don't really feel that anymore.
Looking through my .emacs for things I, personally, have written:
- A little hook to use an external Python program (cheating, I know) to look up the definition of the word under the cursor in the OS X dictionary.
- Several customizations for org-mode, which I use for anything where I want to make an outline, including and especially to-do lists.
- I actually still have some code to do "smart tabs" (http://www.emacswiki.org/SmartTabs) for some modes, though that's now probably obsolete if I would only configure up the code mentioned in that list for C modes. (I'm already using it for e.g. Python code.)
- Some configuration for LaTeX editing, like packages AUCTeX doesn't know about, converting words/phrases into \gls (glossary) references.
I actually have less custom stuff in .emacs than I thought. Having a programmable editor does mean that it's relatively easy for other people to write some really useful stuff which I then get to use. I have some local modifications to other people's packages which I don't have time to enumerate right now.
I can't answer your whole question or we'll be here all day. Here's one important example, which has the advantage of applying in vim as well as emacs:
"Common" macros are the least interesting. The most interesting macros are the ones with no name, the one-time ones that you build on the fly. You have a file with ten thousand lines of:
foo.rb
bar.rb
baz.rb
…
… [9997 more lines like these]
and you need to turn the file into something like this:
// Run the foo command
def foo()
end
// Run the bar command
def bar()
end
// Run the baz command
def baz()
end
… [9997 more blocks like these ]
That's 56 keystrokes in emacs: You record a macro that transforms one line appropriately, then execute it 9999 more times, all on the fly in about twenty seconds.
2. `command + shift + L` to split the multi-line selection into multiple single line selections (one curser at the end of each line)
3. `delete delete delete` to get rid of ".rb" on each line
4. `command + shift + ←` to select the identifier
5. `command + C` to copy each identifying word on each line (!!!!)
6. `←` to get to the beginning of the line
7. Type "// Run the "
8. `command + V` to paste each identifier on each line correctly (!!!!)
9. Type " command\ndef "
10. `command + →` to go past the identifier already there
11. Type "()\nend\n"
Also took about twenty seconds. This multi curser thing has been completely redefining how I mass edit code - it's quite fantastic, and as far as I know ST2 is the only editor that does it this wonderfully.
Multiple carots, the minimap and ST2 picking your indentation strategy automatically by looking at the file (I work with badly formatted legacy code a bit, there is no project-level strategy that applies) are the three reasons I bought it.
Some of my coworkers use sublime, and have been very excited about it. I used vim for several years and use emacs now, so probably a hard sell. Still, I get curious when people are Really Excited about other editors (because there may be ideas worth stealing and adding to emacs ;) ).
What's the "minimap", the scrollbar that is a shrunken version of the document? The "multiple carets" feature seems handy. Are there any other standout features, compared to vim or emacs (not, say, TextMate)?
Yes, the minimap is what you guessed it was. Other ST features that Vim/Emacs don’t have (by default, at least):
• You can use proportional fonts (I use Verdana)
• The interface chrome is graphical, not text in a grid. This allows nice details such as a drop-shadow from the minimap when it covers the text and proportional fonts in the file tree’s filenames.
• On a Mac with smooth scrolling, you can scroll smoothly pixel-by-pixel, instead of choppily line-by-line.
• You can easily rename a variable, by using Command-D repeatedly to select the instances of the names inside multiple carets. But I usually forget to do this until after I’ve already renamed just one instance of the variable, and then I can’t select the other instances without undoing that edit first, so it’s not that useful.
• It uses Python as its scripting language, so you can use Python libraries easily, and don’t have to learn an editor-specific language. Similarly, it uses JSON for settings.
But Sublime Text doesn’t have nearly as many editing shortcuts by default as Vim. For instance, there isn’t any hot-key to select inside a quoted string – Expand Selection to Scope is the closest, but it’s hard to predict what it will do and so it isn’t very reliable. You can enable Vintage mode, which emulates many Vim key-bindings and thus gives you access to that power. That mode has a few small problems – the biggest one for me is that the Esc shortcut to exit the current mode sometimes conflicts with the Esc shortcut to remove extra carets so you have just one.
It’s too bad Sublime Text isn’t open source. Its plugin API doesn’t allow setting tabstops manually, which I would like so I could write a plugin implementing true elastic tabstops. Since I can’t implement it myself, I have no option but to beg the developer to implement that and wait.
Vim uses what my terminal uses. No ideas if my terminal(terminator) allows proportional fonts, but I always have used monospaced. Proportional looks ugly to me when it comes to code.
> The interface chrome is graphical, not text in a grid. This allows nice details such as a drop-shadow from the minimap when it covers the text and proportional fonts in the file tree’s filenames.
Drop shadows? Umm, no thanks.
> On a Mac with smooth scrolling, you can scroll smoothly pixel-by-pixel, instead of choppily line-by-line.
Either I search for what I am looking for, jump to definition, or move screen by screen. I don't scroll - at all. If I did, I am reading lines of code, not rows of pixels.
> You can easily rename a variable,
I don't use ST and can't exactly understand what is unique here, but I am pretty sure renaming something is something vim is very good at. You want to limit the scope, select visually and run :s on it.
> It uses Python as its scripting language, so you can use Python libraries easily, and don’t have to learn an editor-specific language. Similarly, it uses JSON for settings.
Python is much more mainstream than vimscript, yes, but there are still people who don't know python and don't want to learn it. Learning python for them isn't very different from learning vimscript.
>> It uses Python as its scripting language, so you can use Python libraries easily, and don’t have to learn an editor-specific language. Similarly, it uses JSON for settings.
>Python is much more mainstream than vimscript, yes, but there are still people who don't know python and don't want to learn it. Learning python for them isn't very different from learning vimscript.
You've quite obviously never tried to code anything in vimscript, have an axe to grind with Python, or are Tim Pope. Vimscript is a horrible abomination that's painful to do just about anything in. Python is far, far superior.
(Vim lover and Ruby guy here, but I'd pick just about any language over vimscript)
> You've quite obviously never tried to code anything in vimscript, have an axe to grind with Python, or are Tim Pope
All your claims are preposterous. I have coded in Vimscript, I use Python and have no axe to grind; and I am not Tim Pope(duh).
> Vimscript is a horrible abomination that's painful to do just about anything in. Python is far, far superior.
I don't remember claiming Python is inferior to vimscript. Have you actually used vimscript, or are you speaking from superficial experience? Vimscript is not a general purpose programming language, but does the job of extending vim fine.
I was in middle of writing a small function which syncs up nerdtree highlighting with bufexplorer buffer switch(came here to take a break). Here is what it looks like:
function! ChangeBuffer()
if bufwinnr(t:NERDTreeBufName) != -1
exe "normal! :NERDTreeFind\<cr>\<c-w>\<c-w>"
endif
endfunction
let g:BufExplorerFuncRef = function('ChangeBuffer')
The amount of general purpose programming involved is minimal.
1. BufExplorer provides a hook which takes a function reference. A variable assignment.
2. If nerdtree is active(simple function call), call the command to find the current buffer in nerdtree(vim specific normal command execution), and switch back to editing pane(again normal mode command)
A good part of tasks make use of exe, nnoremap, iabbrev etc; and vimscript is powerful and pleasant enough for the rest(lists, dicts, simulated objects, variable namespacing...). It has it's quirks, but so has many mainstream languages - you know about the quirks when you are using the language, and avoid them.
> Vimscript is not a general purpose programming language, but does the job of extending vim fine.
If you have the chance to choose to invest time in learning either a language to extend your editor or a general purpose language which you can use to extend your editor, which would be your best bet?
> If you have the chance to choose to invest time in learning either a language to extend your editor or a general purpose language which you can use to extend your editor, which would be your best bet?
It's not as uni-dimensional. Sure if I don't know either of Vimscript or Python, I will see learning Python as more beneficial. But the main reason vim chose vimscript(or emacs chose elisp) is you have a interpreter built in the editor itself. If all your extensions are vimscript, all you need to configure vim on a new box is to copy your .vimrc and .vim folder and everything will work - no package installation, no external dependencies.
If you already know vim and some programming, you can start writing basic vimscript in an hour or two. The more complicated ones(the ones Time Pope writes) are going to take a lot of time, irrespective of your language choice.
Also, vim extensions can be written in Python as well, but it requires that your vim has python support. How does ST does it? Does it bundle python?
The problem with application-specific extension languages is that they may start underpowered and ad-hoc, whilst general purpose languages have already proved their worth and done so in several domains.
Vim designers tried to reinvent the wheel and failed to implement a decent extension language from the beginning, whilst GNU Emacs designers didn't reinvent the wheel and adapted a mainstream general purpose language to their needs. So, while Vim users were busy wrestling with the limitations of their extension language and coping by adding ad-hoc extensions here and there, Emacs users were busy churning out macros and packages for their editor.
The main reason I have chosen Emacs as my editor is that I get more bang for the buck. Emacs can emulate Vim, whilst the opposite is not true, as the folks who tried to port SLIME (a powerful package to code in Common Lisp) realized.
We agree that an embedded extension language is the way to go. And whatever mainstream language you might choose, it could go out of fashion after a while anyway.
> The problem with application-specific extension languages is that they may start underpowered and ad-hoc, whilst general purpose languages have already proved their worth and done so in several domains.
The embedded language has to be small, easy to learn, and most importantly, it should serve the purpose of extension. If it can serve other domains as well, that isn't really relevant as far as the editor is the concerned. Now vimscript doesn't do threading or evented io or thousands of other things - it isn't meant to do any of those.
> whilst GNU Emacs designers didn't reinvent the wheel and adapted a mainstream general purpose language to their needs.
Lisp can hardly be considered a mainstream, general purpose language(may be it was at the time they were adding it to emacs).
The point of vimscript wasn't to win any language design awards, but to have a langauge with a very small core which can be used for configuration and extension. As far as quirks go, all languages have quirks. PHP and JS probably have more quirks than Vimscript. Since you are so critical of Vimscript, care to cite me the pain-points which stop you from writing decent extensions in vimscript? There are a variety of scenarios in which vimscript implementation is much more simpler to an elisp implementation.
viw<leader>g: Visually select a word, then grep for it.
<leader>g4w: Grep for the next four words.
<leader>gt;: Grep until semicolon.
<leader>gi[: Grep inside square brackets.
Are you saying elisp implementation of the same concept(provide me a way to grep for arbitrary grep for words, and no, spawning a shell isn't the same thing) is going to be shorter or simpler?
> While Vim users were busy wrestling with the limitations of their extension language
I would really like examples where the limitation of vimscript is outshined by elsip. Check my snippet above - vimscript is written specifically for extending vim, and it does a good job.
> Emacs users were busy churning out macros and packages for their editor.
I find recording macros in vim simpler than emacs. By default. Vim doesn't have a save macro functionality, but either you use an extension to do that, or manually save the macro.
> The main reason I have chosen Emacs as my editor is that I get more bang for the buck.
It mostly boils down to this "I get more bang for the buck". There is not much objectiveness when it comes to vim and emacs. You enjoy emacs, I enjoy vim.
> Emacs can emulate Vim,
A very limited form of vim navigation.
> whilst the opposite is not true, as the folks who tried to port SLIME (a powerful package to code in Common Lisp) realized.
I didn't know about an attempt to port slime to vim, because you will have to fight vim for it, and vim won't yield. Vim doesn't do async processes and per the developers, it's not going to, period. So, no shells in the vim(you can folk a shell but then the editor goes away and when you exit the shell, you are back in the editor), no debugger, no slime...It's a conscious design decision. If you don't like it, use something else.
> Now vimscript doesn't do threading or evented io or thousands of other things - it isn't meant to do any of those.
Neither does Emacs Lisp. But whilst Emacs Lisp started as a simplification of a battle-tested general-purpose language, Vim Script started as a hack and continued that way, with further functions being added on a "as-needed" basis.
> As far as quirks go, all languages have quirks. PHP and JS probably have more quirks than Vimscript.
Effective analogy. PHP and Javascript started as hacks as well, they weren't meant to do much at first, and shared the same fate of Vim Script. The reason people put up with PHP and Javascript is that they had or have no alternative. And if there were no modal editor other than Vim, I myself would put up with Vim Script as well.
> Since you are so critical of Vimscript, care to cite me the pain-points which stop you from writing decent extensions in vimscript? There are a variety of scenarios in which vimscript implementation is much more simpler to an elisp implementation.
This is what we could name a "Perl fallacy": Perl scripts can be much shorter than scripts in other languages, but the former are more of a PITA to write.
However, I can cite a pain point: I can't write stand-alone applications with Vim Script. You may say this does not matter, because we are talking about extension languages here, but my view is different (and this was one of the original objections of mine). Why learn shell scripting (or something similar), different command-line text processing tools with their quirks when you can learn one framework well and use it for everything?
Evidence shows that Emacs' packages can go beyond Vim's, even when we factor out the kitchen-sink approach of Emacs. For instance, whilst Emacs programming packages parse - thus understand - code while perform syntax-highlighting, Vim's packages rely on regexps, thus messing syntax-highlighting when the syntax of a language is not quirky.
I don't understand your grep example, but providing an Emacs Lisp implementation would be pointless anyway. Languages are not to be judged so much by the terseness of their programs in specific cases as by their consistency and easiness of reading in general cases. Vim Script code is difficult to read because uses keyboard macros heavily, and suffers from accumulated cruft, where equivalent Emacs code would use named procedures with meaningful and consisten names.
> I find recording macros in vim simpler than emacs.
By "macro" I meant procedures, not keyboard macros.
> It mostly boils down to this "I get more bang for the buck". There is not much objectiveness when it comes to vim and emacs. You enjoy emacs, I enjoy vim.
I wish this were the case, but it is not. There is objectiveness. By learning Emacs, you are learning how to use a tool which is much more consistent and flexible. Since the learning effort is comparable, why would you choose otherwise? Concentrated effort on worthwhile tasks leads to higher returns.
>> Emacs can emulate Vim,
> A very limited form of vim navigation.
Current Emacs packages emulate Vim as far as it is useful. Cloning Vim wouldn't make sense as there are equivalent Emacs facilities.
> I didn't know about an attempt to port slime to vim, because you will have to fight vim for it, and vim won't yield. Vim doesn't do async processes and per the developers, it's not going to, period. So, no shells in the vim(you can folk a shell but then the editor goes away and when you exit the shell, you are back in the editor), no debugger, no slime...It's a conscious design decision. If you don't like it, use something else.
I acknowledge that the kitchen-sink approach of Emacs has lead to aberrations (like Gnus), at which Vim users laugh, but the superiority of Emacs would persist even if you stripped out facilities that Vim doesn't offer by design choice.
You know what, Irahul? I like Vim. Really. I have studied many Vim books and lurked on Vim Wiki and Vim enthusiast's blogs. I have never learned how to use Emacs' default editor properly, as I switched to a Vim emulator early. Emacs has an effective editor implementation, Vim has an effective editing model. That's what is objective. Thankfully, we don't have to choose anymore.
> Vim Script started as a hack and continued that way, with further functions being added on a "as-needed" basis.
Why shouldn't adding functions on "as-needed" basis be the case? No body can see what might be needed in the future. All programming languages evolve, so does vimscript. Other languages evolve in favor of language design and libraries, vimscript adds things which are needed.
> This is what we could name a "Perl fallacy": Perl scripts can be much shorter than scripts in other languages, but the former are more of a PITA to write.
"Perl fallacy" isn't something accepted and proved. It's mostly Python and Ruby folks bashing perl. I have written substantial amount of perl, python, ruby(and lots others, but these 3 are almost interchangeable) and I find perl easy to read and write.
> I can't write stand-alone applications with Vim Script. You may say this does not matter, because we are talking about extension languages here, but my view is different (and this was one of the original objections of mine).
You said it yourself, and I will repeat it. Vimscript exists only to extend vim, and everything that's added to it is added with that in mind. Anything that helps vimscript better at extending vim is good, anything else is not bad but is irrelevant.
> Why learn shell scripting (or something similar), different command-line text processing tools with their quirks when you can learn one framework well and use it for everything?
Well then there has got to be a reason we don't have this magical framework yet which we can use for everything. May be "right tool for the job"?
> Evidence shows that Emacs' packages can go beyond Vim's
Would love to look at some of that evidence. Apart from async stuff(debuggers, slime etc), I don't think that should be the case. I have looked at Tim Pope's and scrooloose's vim plugins, and have reasonable experience writing vimscript and looking at others' work to believe vimscript is powerful enough for the job.
> For instance, whilst Emacs programming packages parse - thus understand - code while perform syntax-highlighting, Vim's packages rely on regexps, thus messing syntax-highlighting when the syntax of a language is not quirky.
Look at the syntax highlighting section 28-107 and show me where it's parsing go code. I don't know what you meant by "parse and understand code", but a parser for a non-toy language isn't something you write in elisp for a syntax highlighter.
Syntax highlighters more or less work the same way. You have a colorscheme which says keywords are blue, and then the highlighter tells what is to be considered a keyword. Now keywords is cakewalk - a static list of tokens, and in most editors, if you name your variable `class`, it gets the same highlighting as the keyword class. Regions(multi-line comments, multi-line strings, function arguments falling down to next line) are a bit problematic, but editors have hooks for it.
# Well, thank's slosh again.
# http://learnvimscriptthehardway.stevelosh.com/chapters/47.html
syntax region potionString start=/\v"/ skip=/\v\\./ end=/\v"/
highlight link potionString String
Now,
"She said:
\"Vimscript is tricky, but useful\"!".
will highlight as string just fine.
> Vim Script code is difficult to read because uses keyboard macros heavily, and suffers from accumulated cruft, where equivalent Emacs code would use named procedures with meaningful and consisten names.
It is difficult to read to whom? Unless it is difficult to read to someone who knows vimscript, it doesn't matter.
You are missing the point. When I am in the editor, and I need to copy 2 words, I do y2w. Making it a function call in vimscript isn't beneficial to me at all. What exactly would I gain if vimscript, instead of this:
> Why shouldn't adding functions on "as-needed" basis be the case? No body can see what might be needed in the future. All programming languages evolve, so does vimscript. Other languages evolve in favor of language design and libraries, vimscript adds things which are needed.
When you add things when needed instead of thinking them through beforehand, you have two choices:
- forsaking backward compatibility, thus breaking existing libraries;
- striving for backward compatibility, thus ending up with an inconsistent framework and language quirks.
Examples are not rare:
- Perl and its flattened lists and many other quirks;
- PHP;
- Python warts;
- C++ with weird syntax which is legit;
- etc.
> It's mostly Python and Ruby folks bashing perl. I have written substantial amount of perl, python, ruby(and lots others, but these 3 are almost interchangeable) and I find perl easy to read and write.
Props, man. You must have a big brain, if you feel that both Python and Perl have almost the same cognitive load. I considered myself to be a sharp blade at programming C++, yet I have always found it to be a taxing task. Good for you. I'm not joking.
> Vimscript exists only to extend vim, and everything that's added to it is added with that in mind. Anything that helps vimscript better at extending vim is good, anything else is not bad but is irrelevant.
But you can't deny that an extension language which goes beyond its editor comes with a bonus.
> Well then there has got to be a reason we don't have this magical framework yet which we can use for everything. May be "right tool for the job"?
Such magical framework exists. Its name is GNU Emacs. Sometimes its magic has been overplayed, but still...
>> Evidence shows that Emacs' packages can go beyond Vim's
> Would love to look at some of that evidence. Apart from async stuff(debuggers, slime etc), I don't think that should be the case. I have looked at Tim Pope's and scrooloose's vim plugins, and have reasonable experience writing vimscript and looking at others' work to believe vimscript is powerful enough for the job.
What about:
- Gnus, RM, VM, Vanderlust, Meow: mail readers (IMO an aberration, but it proves the point);
- Eshell (Emacs shell, written in Emacs Lisp);
- Dired, Sunrise Commander: file browsers;
None of these packages uses functionality which is alien to Vim, except a more expressive extension language and a richer library.
> http://code.google.com/p/go/source/browse/misc/emacs/go-mode....
>
> Look at the syntax highlighting section 28-107 and show me where it's parsing go code. I don't know what you meant by "parse and understand code", but a parser for a non-toy language isn't something you write in elisp for a syntax highlighter.
That's a basic Emacs mode. Throw some Perl code to both CPerl in Emacs and to Vim and see which of the two copes better (with Perl you can't do better than coping).
>> Vim Script code is difficult to read because uses keyboard macros heavily, and suffers from accumulated cruft, where equivalent Emacs code would use named procedures with meaningful and consisten names.
> It is difficult to read to whom? Unless it is difficult to read to someone who knows vimscript, it doesn't matter.
It is difficult to read to everyone. There is a reason for we using named variables instead of codes of registers nowadays.
> You are missing the point. When I am in the editor, and I need to copy 2 words, I do y2w. Making it a function call in vimscript isn't beneficial to me at all.
What happens if the reader has remapped such keys on his Vim? I don't know, but either your code will break or the user will risk misunderstanding it. Maybe Vim doesn't offer you any facility to easily convert keyboard macros to named procedures, therefore you have to resort to hardcode such macros.
What if the reader uses a subset of Vim's commands and doesn't recognize the hard-coded macro at first sight? She has to decrypt it. In Emacs Lisp, you always have at least clue about what a command does.
>> Unless you have objective proof of "emacs being much more consistent and flexible(where, how)" it's not objective at all.
That Emacs is more flexible, I have proved. Documenting why Emacs is more consistent would be more work than I'm willing to put into a comment here. Since I have studied both Vim and Emacs and read experiences of users who have switched from one to the other, both ways, I believe I have a good idea about how they stack one against the other. I accept that you don't share my opinion.
Bad bad bad, if you are investing time in mastering a tool which could disappear tomorrow, or take a direction you don't like. This is one of the strongest reasons I chose GNU Emacs as my editor. I remember how burned I was when Visual Studio moved from VBScript to .NET as its macro language. All the time I had invested in learning its macro system and in writing macros went down the drain. Never again.
"Its plugin API doesn’t allow setting tabstops manually, which I would like so I could write a plugin implementing true elastic tabstops."
Elastic tabstops are awesome. This is a feature I do miss in Emacs.
To be completely fair, it's not like they are going to remotely delete it or anything, the current version which I like functions, and has no glaring bugs, and will continue to function.
And if I did use emacs, and somehow it changed in a way that I hated, I really doubt I'd have the time to fix it. Work isn't going to pay me to sit around and write my own text editor.
I see your point. One day I'm going to write a guide to choosing your editor, or your trusty tools, for that matter. There are further advantages in choosing an open-source established editor.
It all boils down to a trade-off. As long as you don't invest too much time into learning a tool, you don't mind losing your investment. Recently I have switched to Opera as my default browser. I couldn't stand Firefox anymore, Chrome didn't suit me. Opera is proprietary and closed-source, but then I'm not going to dig too much into its internals.
Ok. I can see many of those being possible advantages, depending on taste. I find the option of a terminal (rather than a graphical interface) to be a major asset, because then it works with ssh* .
Also, all the people I know using ST are ex-vimmers, and use its vim emulation mode. A data point, I suppose.
And yes, agreed on the open-source-ness, though commercial support does have its advantages.
* I know you can do X forwarding and so on, but, eh.
This looks unwieldy but it's all done interactively. (also if you mess up and you want to rework the macro you can paste it out with "rp to paste the r register rework it and then put it back into another register. 0"ry$ (start at column 0 then into r register r yank to end of line)
As a heavy user of regex one liners, I agree in this case, but as a heavy user of vim, there are lots of times when a macro can be recorded and run over a file long before a proper regex can be constructed, particularly in multi line settings, or those things that would require heavily nested backrefs.
Then enter this sequence of keystrokes[1]:
0veyO// Run the ^R" command<esc>j0f.C()<cr>end<cr><esc>
Then exit macro recording with:
q
Then enter the command:
:g/.rb$/ norm @a
to run the macro on every line ending with .rb (allowing comments in the input, just because (of course it would be nice to make that regex in :g look for "lines that start with comments" and ignore them explicitly)).
If I counted right, thats 57 keystrokes, and I might have been slightly inefficient in my usage, of course, if that one keystroke is part of a command my fingers just do, there is no effective difference :)
[1] I know it was exactly that sequence because I just pasted the macro buffer, which of course can then be edited, saved back to the buffer and run in edited form.
I'm an intermediate user of vim but the filtering the macros to only run on those lines is a great tip! I did it a bit different but we had a similar idea.
I probably define ad-hoc macros 10-15 times a day These are for tiny things that save me a minute or two each time I use one. More than the time savings, though, is the sanity savings. I've it's rare now that I do any sort of repetitive editing task.
Also, you don't have to actually program the editor yourself to reap the benefits of a programmable editor. Let's be honest, most modern editors have mostly overlapping functionality. However, one of the benefits of emacs being programmable is that it's self documenting. I can find out how to capitalize a word problematically without having to go to google by using `M-x apropos RET capitalize RET`.
A mini calculator function, lots of snippets, some saved macros etc.
It's not about changing keyboard shortcuts. It implies you can only remap what already exists. It's about giving you infinite canvas to paint on. This isn't unique to Vim. I am just saying having the capability to do so is important.
The thing is once you can code in emacs, and even when you can use the keyboard macro utility, you constantly find little time saving ways to use it. At first though they're not even time saving, they take longer. Anyhow some examples:
I have a function for my work log which gets the date, figures out the previous Monday's date and dumps a formatted weekly log for me to fill out.
I wrote an entire budget tracking application which generates a forecast and dumps it to a csv file
Wrote a utility to mark and optionally delete duplicate files in a dired buffer
Convert a windows path name to a cygwin one
Functions to add local sales tax and remove local sales tax, same for tips.
Perforce source control, helpers to do blame functionality and other stuff that benefits from pulling Perforce output into a buffer
The most used feature would be keyboard macros which are endlessly useful for any repetitive editing task, which can show up unexpectedly at any point of the day
Occasionally have to write throw away custom code to create some boiler plate code, such as turn the API documentation for some errors into a C++ array of structures that can be manipulated in code
"Keyboard shortcuts can be changed in lots of editors and OS's."
Yes, but you can't change the editing model as easily, e.g. converting a modeless editor in a modal one just by changing a few shortcuts.
My take is that there are two camps: people who adapt themselves to the tools they use and people who try to adapt their tools to their ways and their ever-changing view of the world. The former want the tool to help them to get things done, the latter want the tool to help them to get things done their own way. The former look at tools as tools, the latter look at tools as extensions of themselves.
Restarting a program (in various profiles) for tight dev cycles; running unit-tests appropriate to the file I'm currently looking at; using REPLs (Redis, etc); publishing stuff to servers; hacking games which emacs ships with; going through a file and rolling increment certain numbers; and so on.
I used emacs for about 6 months, and just recently switched to vim to see what I think. It's been pretty subtle so far; close enough that I don't know how much the choice matters.
