Irrelevant, they're still separate logic for each kind of kill. See:

    10 matches for "^(defun kill-" in buffer: simple.el.gz
       3218:(defun kill-new (string &optional replace yank-handler)
       3270:(defun kill-append (string before-p &optional yank-handler)
       3340:(defun kill-region (beg end &optional yank-handler)
       3411:(defun kill-ring-save (beg end)
       3605:(defun kill-forward-chars (arg)
       3611:(defun kill-backward-chars (arg)
       3679:(defun kill-line (&optional arg)
       3734:(defun kill-whole-line (&optional arg)
       5049:(defun kill-visual-line (&optional arg)
       5354:(defun kill-word (arg)

Vi as one notion of deletion that is parameterized by a region(or movement in vi slang I believe), which is bound to a set of keys.

It's not irrelevant. For most uses, mark the point, move, kill-region.

I vastly prefer doing operations over explicit regions, instead of composing editing operations as in vi. Especially since this maps better to other forms of editing.

vim allows you to select a region and operate on it. It sometimes necessary, but in practice, people use the compositional commands. They are faster and mentally easier. So empirically it seems your preference is different than most.

Also, what do you mean, maps better to other forms of editing?

I think you're getting close to some important points.

I think Sublime Text's multiple-cursor editing is nice because I can see where the focus is and get immediate feedback, much better than "replace-all" even if the end result would be the same. Bret Victor style.

So most of the real complexity in the interface is about region-selection, and the operations are actually trivial.

Of course, you need to first select regions (like interesting lines), then select other regions within those, others within those etc. How to chain it all in a natural way?

Both vim and emacs have multiple-cursor plugins.[1][2][3]

[1] - http://www.vim.org/scripts/script.php?script_id=4523

[2] - http://emacsrocks.com/e13.html

[3] - https://github.com/magnars/multiple-cursors.el

The multiple-cursor is a nice blend between stateful things like regexp-replace and the purely stateless isolated ones likes vi :s/foo/bar/g

Sometimes you want feedback without leaving the declarative paradigm.

With Emacs in Evil mode, :%s/foo/bar/ also shows you the potential replacements as you type.

It seems backward to me.

I want to delete a domain object (in the context of text, most objects are chars, words, sentences, paragraphs). So I tell the system delete ('d'), then what I want to delete, almost declarative (the what).

Emacs requires to explicitely tell him to create two pieces of data (begin and end marks) then ask for deletion (~the how).

Quantitatively it's also heavier, since it's a 2 keystrokes in vi, and 3 in emacs.

If you have used a Lisp Machine with something like Zmacs for an extended time, then one often manipulates with the mouse. Same sequence: mark, execute. For some things there is also modifier-click on something visual which creates a region.

Thus the whole select the object, execute sequence is the same:

* emacs keystrokes

* mouse manipulation

* Lisp functions: get the arguments, execute a function

Thus it is a very consistent model.

Unfortunately I never had such pleasure. I understand a little more the appeal to have consistency between mouse and keyboard operations.

Maybe I'm more a schemer than a lisper then because even though the function call protocol is eval args, eval body, one of the nicest thing about lisps is higher order functions. Vi feels exactly like this; a move is an abstract operation that can live on its own, or be passed to another abstract operation to be combined.

To the extreme it reminds me of point-free programming where you dont even pass ~toplevel arguments, you just accumulate hof.

> It seems backward to me.

That's just unfamiliarity. Spanish initially seemed backwards to me because they say "casa blanca" and not "white house", but you get used to it.

I've used all sorts of user interaction schemes, I don't think that's habit anymore.

It's an unnecessary explicit operative order. Like saying writing assembly code is just like C backwards, you'll get used to write callee saved arguments on the stack.

You can only say those are bound to different functions because they are visible to you. Are you sure Via, under the hood, is not the same? Also (can't check it right now), these lisp functions can all be calling the same mechanism with different parameters, being only declared separately for convenience.

To be honest I don't have the slightest idea about how vi does it, but it feels like the design is operations taking 'move' entity as argument.

I glanced a bit at the actual elisp, it's not trivial dispatch, it's multiline intertwined bits of logic.

And even then, to the user it doesn't matter, the composability is hidden from him, making learning longer and failing to expose a very valuable concept entirely.

Some very interesting software pushed the idea of composability to visual tools even, look at Luxology Modo, where you can merge small widgets/tools into the one you need. Very neat.

Yes, it is not the same under the hood. You can easily define new motions in vim (eg. I have a plugin in vim that adds “aa” (=an argument) - a motion that selects one argument in a function call. And all vim functions will work with that motion.

All of those function call kill-region, FWIW. The extra code defines which region and handles things like attempts to kill text that is wholly or partially read-only.