[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

`C-b' is backward-char, `left' is left-char - why?

From: Drew Adams
Subject: `C-b' is backward-char, `left' is left-char - why?
Date: Fri, 27 May 2011 13:40:37 -0700

I'm curious. Why is it a good idea that `C-b' and `left' are no longer bound to
the same command?

I'm not asking about the difference; I can see that from the doc strings.  I'm
wondering why we've broken their longstanding correspondence.

Lots of Emacs and Emacs Lisp does things based on which commands are used.  It's
sometimes not enough that two commands behave the same or similarly.  If they
are different commands then some code will likely not DTRT - some code will at
least not treat them the same.

Even if the bidi stuff specifies the same behavior for `backward-char' and
`left-char' whenever there is in fact no bidirectional stuff present, that does
not mean that Emacs will behave the same for these two keys, simply because they
are bound to different commands.  As a trivial example, if you have code that
remaps or uses `substitute-key-definition' with `backward-char', it will no
longer work for `left' as well as `C-b'.

Why not make bidi optional?  Why not have a minor mode for the bidi stuff, and
only bind keys such as `left' to commands that are specific to bidi when that
mode is turned on?  Why make such an invasive, top-level change to Emacs?

I understand that bidi is a great addition to Emacs and will be welcomed by
folks around the world.  I also realize that it is complex to implement.  But
some of us will rarely, if ever, use it.  A priori, it doesn't seem like a great
idea to be changing basic default key bindings.

I say "a priori" because I would like to understand why this is necessary or a
good idea.  I'm not claiming it's a bad idea and should be undone.  Chalk it up
mainly to surprise, if you like: I was surprised to see that `C-h w
backward-char' did not list `left' as well as `C-b'.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]