info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Missing default functionality hurts emacs adoption
37 views
Skip to first unread message
Blake McBride
Sep 19, 2012, 12:53:47 PM9/19/12
to
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
Brendan Halpin
Sep 19, 2012, 1:26:22 PM9/19/12
to
I can see your point about kill-line-remainder, though I am happy with
the default.
However, I think insert-line-before and insert-line-after are the sort
of thing that make sense only in the paradigm of line-oriented editing,
i.e., the desire for them is an artifact of limitations of (earlier
versions of) vi. With screen-oriented editing, the principle of least
surprise would suggest that edits should normally happen at point.
That said, it's no harm to discuss what optimal editing behaviour should
be.
Brendan
--
Brendan Halpin, Department of Sociology, University of Limerick, Ireland
Tel: w +353-61-213147 f +353-61-202569 h +353-61-338562; Room F1-009 x 3147
mailto:brendan...@ul.ie ULSociology on Facebook: http://on.fb.me/fjIK9t
http://teaching.sociology.ul.ie/bhalpin/wordpress twitter:@ULSociology
the default.
However, I think insert-line-before and insert-line-after are the sort
of thing that make sense only in the paradigm of line-oriented editing,
i.e., the desire for them is an artifact of limitations of (earlier
versions of) vi. With screen-oriented editing, the principle of least
surprise would suggest that edits should normally happen at point.
That said, it's no harm to discuss what optimal editing behaviour should
be.
Brendan
--
Brendan Halpin, Department of Sociology, University of Limerick, Ireland
Tel: w +353-61-213147 f +353-61-202569 h +353-61-338562; Room F1-009 x 3147
mailto:brendan...@ul.ie ULSociology on Facebook: http://on.fb.me/fjIK9t
http://teaching.sociology.ul.ie/bhalpin/wordpress twitter:@ULSociology
Pascal J. Bourguignon
Sep 19, 2012, 1:29:14 PM9/19/12
to
Blake McBride <bl...@mcbride.name> writes:
> [nice features]
So you want those features to be provided by default by emacs?
But then newbies won't be motivated to learn emacs lisp!
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
> [nice features]
So you want those features to be provided by default by emacs?
But then newbies won't be motivated to learn emacs lisp!
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
Blake McBride
Sep 19, 2012, 1:39:27 PM9/19/12
to
On 2012-09-19 12:29:14 -0500, Pascal J. Bourguignon said:
> Blake McBride <bl...@mcbride.name> writes:
>> [nice features]
>
> So you want those features to be provided by default by emacs?
> But then newbies won't be motivated to learn emacs lisp!
Lisp is one of the most beautiful and elegant things I have ever
> Blake McBride <bl...@mcbride.name> writes:
>> [nice features]
>
> So you want those features to be provided by default by emacs?
> But then newbies won't be motivated to learn emacs lisp!
experienced. Getting other programmers to see the beauity I see has
not been a talent I have.
The fight for the survival of emacs and lisp are independent.
Blake McBride
Sep 19, 2012, 1:40:20 PM9/19/12
to
I suppose my exception to your comment would be that programming (which
propably represents the largest group of emacs users) is often line
oriented. Statements are usually organized on a line-by-line basis
(i.e. one statement per line). Adding a new line of code after the
line you are on is a very, very common thing. Being able to add a new
line of code without having to unnecessarily take into account your
position on your current line make a lot of sense.
propably represents the largest group of emacs users) is often line
oriented. Statements are usually organized on a line-by-line basis
(i.e. one statement per line). Adding a new line of code after the
line you are on is a very, very common thing. Being able to add a new
line of code without having to unnecessarily take into account your
position on your current line make a lot of sense.
steve
Jul 9, 2021, 9:13:42 PM7/9/21
to
The first time I used vi I executed a remote shell and fixed the passwd
file so I could log back into the system. Try doing that with emacs,
a floppy disk, and 9600 baud modem :)
Andreas Eder
Jul 10, 2021, 4:15:03 AM7/10/21
to
'Andreas
0 new messages