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

[Eli Zaretskii]

> From: "Drew Adams" <address@hidden>
> Date: Fri, 27 May 2011 16:19:16 -0700
> 
> > why do you need "C-f" and "right" to be the same thing?
> 
> I don't.  Why do we need them to be different, by default?
> 
> That's the question I posed (`C-b' and `left', actually).

Btw, the same "problem" exists with `M-f'/`M-b' and
`C-<right>'/`C-<left>' as well.  We even discussed the possibility to
make `<Home>' and `<End>' behaving differently, see
https://lists.gnu.org/archive/html/emacs-devel/2010-06/msg00163.html
and the responses.

> Haven't seen an answer yet, except that bidi needs them to be different.

A simple answer is that I didn't see any other solution that is
simpler or more elegant than this one.  If you can suggest one, please
do.  Others explained (and I concur) that a minor mode is neither
simpler nor more elegant (more about that below).  If you (or someone
else, for that matter) have better suggestions, let's hear them.

> The question then is why bidi's-need-for-this needs to become
> Emacs's-need-in-general (all the time, everywhere, for everyone)?

Because experience shows that making such deep, central features
optional means trouble in more than one way.  For starters -- and this
was also mentioned in this thread -- it will make the bidi features
less reliable because many active contributors will opt not to use it
(e.g., because disabling it makes redisplay faster).

We've been through that once, when support for multibyte characters,
a.k.a. MULE, was introduced in Emacs 20.  I was there when it
happened.  If someone wants to put the Emacs community through this
again, I certainly don't, and I'm happy that Stefan and Chong agree.
Given this, you will understand that it is no incident that
bidi-display-reordering is not a user option.  If it's up to me, it
never will be.

Another reason is that once Emacs moved to be based on Unicode, it
needs to strive to support the requirements of the Unicode Standard as
much as possible, because users of word-processing programs come more
and more to expect that.  We already support various parts of that
standard, and we do it by default without any options and knobs.  The
Unicode Bidirectional Algorithm is part of that; that its support
needs significant changes in the Emacs infrastructure is a minor
detail, from the user perspective.  If OpenOffice and Firefox support
it by default (and I don't think you can disable it there), users will
expect Emacs to do the same.

> I mentioned `substitute-key-definition' and `remap'.

These are indeed valid considerations, but a minor mode is not the
solution, because the same problems will exist when that minor mode is
in effect.  Surely, you don't want to suggest that we should forget
about bidi users when we consider the difficulties with `remap' and
`substitute-key-definition'?

So if we don't want these consequences, we should come up with a
solution that works when bidi is in effect as well.  If you can
suggest such a solution, please do, but a minor mode isn't it.