Do you think/write differently in vim and emacs?
Question: In many scripts that I write, I often construct programs in a "functional
style". That is to say, I basically define a lot of functions at the
beginning, and then later apply these functions. This results in a sequence of
nested function calls, wherein I type out:

  1. function name
  2. its arguments
  3. next function name 
  4. its arguments

...and so on.

For cases in which functions are "piped" together, the output of one function
is an argument (usually the first, but not always) to the next function, the
output of which is an argument to the next function, and ad infinitum. In
prefix-notation, the key movements can be very jumpy if you type out this
sequence from left to right. For example, how would you type out the second
line of the following [Python] example (~mul~ is multiply, ~truediv~ is
divide)?

    
    
    from operator import add, mul, truediv
    print(truediv(mul(add(1,1),2),4))
    

If I had to write the same set of operations linearly (from left to write,
without jumping around), I am more likely to use the notation of function
composition. Building on my previous example in Python, I might write

    
    
    from functional import foldr, compose, partial, flip
    print(foldr(compose,add,(partial(mul,2),partial(flip(truediv),4)))(1,1))
    

I think this is because I associate each function with its own arguments and
prefer to type them out in succession, rather than filling arguments to
another function before the argument list for the first function is complete
(as would be required to type out the first example from left to right).

I noticed this because I've been an emacs user for a long time and only
recently tried out viper/vimpuse and vim. In emacs, I might do something like

  1. [type function name and arguments] 
  2. C-a
  3. [type next function name] 
  4. C-e 
  5. [fill in rest of arguments]
  6. C-a
  7. [type next function name]
  8. C-e
  9. [fill in rest of arguments]

...and so on, with occasional use of M-b, M-f, M-DEL (backward-word, forward-
word, backward-kill-word) if I mess up or forget something.

I recently found out about C-o in vim, which is a lifesaver - but I find that
the equivalent keys would be

  1. [type function name and arguments] 
  2. C-o 0
  3. [type next function name] 
  4. C-o $ 
  5. [fill in rest of arguments]
  6. C-o 0
  7. [type next function name]
  8. C-o $
  9. [fill in rest of arguments]

...and the rest; backward-word, forward-word, and backward-kill-word
equivalents would be C-o b and C-o w, and C-w.

So this got me thinking that to program in vim, I may have to grow a larger
working memory, so that I can pause the construction of one function as I fill
out another, and so on down the stack. Also, in construcing text documents, I
find that I edit (kill, copy, yank) quite frequently even before I finish a
complete thought, which is not so amenable for vim's operational style of
"stay in normal mode, burst of text in insert-mode, and back to normal mode",
which seems to presume that I am capable of producing something worth editing
during my forays into insert-mode. To use vim, I find that I deliberate more
as I type to reduce the frequency of switching between modes. Is this because
I'm naturally spastic, or once I master or commit a suitable range of vim key
commands to muscle memory, I'll stop thinking they're so different?

If you program in both emacs and vim, do you find yourself thinking about and
construcing your programs and blocks of text differently in each editor?


Answer: I used vi from the good old days of 1992 and now I use Emacs since 2001. I
haven't noticed any difference in my thinking when programming functions and
blocks of code. Both editors has their own peculiarities and ways of doing
things, but they are not so strong that they could change your way of thinking
and how you program.

I've always tried to find ways to do what I intend to do. I don't let my
editor force me to do something I don't want. When I do procedural programming
of a new piece of code, I use the technique called "wishful thinking" that is
[mentioned in Structure and Interpretation of Computer
Programs](http://mitpress.mit.edu/sicp/full-text/sicp/book/node28.html) :

You imagine yourself in the perfect world having all the procedures you need
at your disposal. You code your algorithm with all those helpful functions
that you'll need to implement but that you only have prototypes for the
moment. It's similar to a top-down approach.

