Blake McBride
2012-09-19 16:53:47 UTC
Greetings,
I have been using emacs as my main editor for about 20 years now. Prior
to that I used VI. Over the last many years I have used VI very
infrequently. My son is taking CS in college. He had need for a
quick, already-installed editor so I decided to write a Wiki page
telling him how to use VI. Writing this page (
http://wiki.arahant.com/wiki/Wiki.jsp?page=Vi ) caused me to re-think
the whole emacs vs. vi debate. This re-thinking led me to some
conclusions that I think could significantly help the emacs community
so I thought I would share those thoughts publicly.
I am not going to compare the various benefits of each editor. My main
concern is why someone would use VI when emacs is so much more
powerful. After some thought I came to the realization that VI does a
handful of things that are among the most common editing functions
needed and used that are significantly and totally unnecessarily
difficult in emacs. In other words, VI does many things that a typical
user wants to do easily and emacs is difficult doing those same basic
tasks.
In spite of this, I realized that the sole reason why I've used emacs
all these years is because from the very beginning I realized the
shortcomings of emacs and I wrote some lisp functions to do what I (and
I think most people) needed. Since I wrote this functionality, I have
had all the advantages of doing the simple things I needed simply, and
then also had all the other benefits to boot.
I think when a VI user starts using emacs (and not knowing lisp like I
do) they immediately get frustrated with a few basic things and they
give up. Emacs enthusiasts would tell them to just stick in there a
little longer but now I think they are wrong. There is a problem
(missing basic functionality that takes custom lisp code to produce)
that is unnecessary, and they can't live with this lack.
So now what is left is for me to make a case regarding this basic
functionality. I can also include the lisp code I use to fix the
problem. All of these facilities are things needed by programmers all
the time and are just cumbersome in emacs as follows.
The first is "delete line". Deleting a line is one of the most basic
functions needed. It is used all of the time. Having to type ^a^k^k is
utterly crazy for such a basic function. It takes two hands and three
keys! VI has two keys and one hand.
Yes, I know that emacs can be customized as desired. And, yes, I know
about kill-whole-line. The problem is not what emacs can do, the
problem is how emacs comes in its default configuration. Expecting a
non-lisp programmer to customize emacs before they can easily delete a
line is crazy and, IMO, has very significantly hurts emacs' adoption
over the years. The default emacs configuration should do every common
function out-of-the-box easily.
Just for the record I use:
(defun kill-line-remainder ()
"Kills the remainder of the line."
(interactive)
(if (not (eolp))
(let ((beg (point)))
(end-of-line)
(delete-region beg (point)))))
(defun kill-current-line ()
"Kills the current line."
(interactive)
(beginning-of-line)
(kill-line-remainder)
(if (bobp)
(delete-char 1)
(progn
(delete-backward-char 1)
(next-line 1)
(beginning-of-line))))
(global-set-key [f5] 'kill-current-line)
(global-set-key [f6] 'kill-line-remainder)
Note that although it may seem (and in fact may be the case) that this
functionality could be added easier, be careful. This code correctly
handles end-of-file conditions as well as other unusual scenarios. It
has been perfected and used over many years.
kill-line-remainder does what you'd expect. It kills the remainder of
the line, period. ^k does different things depending on the situation.
kill-current-line deletes the line you are on with no need to go to the
beginning of the line first and no weirdness if the line has no
characters on it. It is not a matter about doing something logical. It
is a matter of doing things that are intuitively clear.
Rather then make a case for each function independently, I maintain
that each function I show is something naturally desired by a
programmer, easy with VI, and unnecessarily confusing and difficult in
emacs.
The next function adds a new line after the current line. No need to
go to the end of the line first! (VI o)
(defun insert-line-after ()
"Inserts a new line before the current line."
(interactive)
(end-of-line)
(insert "\n"))
(global-set-key [f8] 'insert-line-after)
Insert line before the current line (VI O)
(defun insert-line-before ()
"Inserts a new line before the current line."
(interactive)
(beginning-of-line)
(insert "\n")
(previous-line 1))
(global-set-key [f7] 'insert-line-before)
Scroll screen up or down by one line:
(setq scroll-step 1)
(defun scroll-up-one ()
"scrolls window up one line."
(interactive)
(scroll-up 1))
(defun scroll-down-one ()
"Scrolls window down one line."
(interactive)
(scroll-down 1))
(global-set-key [f1] 'scroll-up-one)
(global-set-key [f2] 'scroll-down-one)
That's it. I have other functions I use but these represent what I
believe to be basic and universally needed facilities. Again, yes,
emacs does all this. It's just too cumbersome, confusing, and
irregular. These work the way a person would intuitively expect them
to work IMO.
Blake McBride
I have been using emacs as my main editor for about 20 years now. Prior
to that I used VI. Over the last many years I have used VI very
infrequently. My son is taking CS in college. He had need for a
quick, already-installed editor so I decided to write a Wiki page
telling him how to use VI. Writing this page (
http://wiki.arahant.com/wiki/Wiki.jsp?page=Vi ) caused me to re-think
the whole emacs vs. vi debate. This re-thinking led me to some
conclusions that I think could significantly help the emacs community
so I thought I would share those thoughts publicly.
I am not going to compare the various benefits of each editor. My main
concern is why someone would use VI when emacs is so much more
powerful. After some thought I came to the realization that VI does a
handful of things that are among the most common editing functions
needed and used that are significantly and totally unnecessarily
difficult in emacs. In other words, VI does many things that a typical
user wants to do easily and emacs is difficult doing those same basic
tasks.
In spite of this, I realized that the sole reason why I've used emacs
all these years is because from the very beginning I realized the
shortcomings of emacs and I wrote some lisp functions to do what I (and
I think most people) needed. Since I wrote this functionality, I have
had all the advantages of doing the simple things I needed simply, and
then also had all the other benefits to boot.
I think when a VI user starts using emacs (and not knowing lisp like I
do) they immediately get frustrated with a few basic things and they
give up. Emacs enthusiasts would tell them to just stick in there a
little longer but now I think they are wrong. There is a problem
(missing basic functionality that takes custom lisp code to produce)
that is unnecessary, and they can't live with this lack.
So now what is left is for me to make a case regarding this basic
functionality. I can also include the lisp code I use to fix the
problem. All of these facilities are things needed by programmers all
the time and are just cumbersome in emacs as follows.
The first is "delete line". Deleting a line is one of the most basic
functions needed. It is used all of the time. Having to type ^a^k^k is
utterly crazy for such a basic function. It takes two hands and three
keys! VI has two keys and one hand.
Yes, I know that emacs can be customized as desired. And, yes, I know
about kill-whole-line. The problem is not what emacs can do, the
problem is how emacs comes in its default configuration. Expecting a
non-lisp programmer to customize emacs before they can easily delete a
line is crazy and, IMO, has very significantly hurts emacs' adoption
over the years. The default emacs configuration should do every common
function out-of-the-box easily.
Just for the record I use:
(defun kill-line-remainder ()
"Kills the remainder of the line."
(interactive)
(if (not (eolp))
(let ((beg (point)))
(end-of-line)
(delete-region beg (point)))))
(defun kill-current-line ()
"Kills the current line."
(interactive)
(beginning-of-line)
(kill-line-remainder)
(if (bobp)
(delete-char 1)
(progn
(delete-backward-char 1)
(next-line 1)
(beginning-of-line))))
(global-set-key [f5] 'kill-current-line)
(global-set-key [f6] 'kill-line-remainder)
Note that although it may seem (and in fact may be the case) that this
functionality could be added easier, be careful. This code correctly
handles end-of-file conditions as well as other unusual scenarios. It
has been perfected and used over many years.
kill-line-remainder does what you'd expect. It kills the remainder of
the line, period. ^k does different things depending on the situation.
kill-current-line deletes the line you are on with no need to go to the
beginning of the line first and no weirdness if the line has no
characters on it. It is not a matter about doing something logical. It
is a matter of doing things that are intuitively clear.
Rather then make a case for each function independently, I maintain
that each function I show is something naturally desired by a
programmer, easy with VI, and unnecessarily confusing and difficult in
emacs.
The next function adds a new line after the current line. No need to
go to the end of the line first! (VI o)
(defun insert-line-after ()
"Inserts a new line before the current line."
(interactive)
(end-of-line)
(insert "\n"))
(global-set-key [f8] 'insert-line-after)
Insert line before the current line (VI O)
(defun insert-line-before ()
"Inserts a new line before the current line."
(interactive)
(beginning-of-line)
(insert "\n")
(previous-line 1))
(global-set-key [f7] 'insert-line-before)
Scroll screen up or down by one line:
(setq scroll-step 1)
(defun scroll-up-one ()
"scrolls window up one line."
(interactive)
(scroll-up 1))
(defun scroll-down-one ()
"Scrolls window down one line."
(interactive)
(scroll-down 1))
(global-set-key [f1] 'scroll-up-one)
(global-set-key [f2] 'scroll-down-one)
That's it. I have other functions I use but these represent what I
believe to be basic and universally needed facilities. Again, yes,
emacs does all this. It's just too cumbersome, confusing, and
irregular. These work the way a person would intuitively expect them
to work IMO.
Blake McBride