Re: Upcoming loss of usability of Emacs source files and Emacs.

[Stephen J. Turnbull]

Alan Mackenzie writes:

 > Perhaps not, as such, but the phrase you used "... risk the wrath
 > of the ASCII-capped lobby?" sounds anything but respectful.

I don't respect the ASCII-capped lobby.  They constitute a tiny
minority of humanity which has been getting in the way of bringing
sane computing to 7 billion people for 5 decades now.  I find the
argument that "*I* am ASCII-capped, so *we* shouldn't simplify and
disambiguate by using Unicode" especially distressing in the context
of Emacs.

 > That's a red herring which has nothing to do with the current
 > argument about curly quotes.  The inconvenience of typing curly
 > quotes is just as much an inconvenience to those who use
 > non-English keyboard layouts.

That's nonsense.  Emacs users learn *hundreds* of keychords.  Learning
a few more to be able to distinguish between ASCII GRAVE ACCENT and
Unicode LEFT SINGLE QUOTATION MARK is not a huge inconvenience.  If
you don't need to do so, then simply map grave to the quotation mark
and you're done.

 > I would imagine (correct me if I'm wrong) you use distinct keyboard
 > layouts for writing in English and Japanese.  I imagine also that
 > there's no key on the Japanese layout either for either of the
 > curly single quotes.

Japanese (and Chinese) mostly just use the layout of whatever keyboard
is in front of them, except that it's convenient to have labelled keys
for mode-switch commands for word processing users.  The process of
entering Japanese text has several levels for most programming users:

1.  Keystrokes.  These are ASCII keystrokes.
2.  Keystroke pairs.  Japanese phonetic writing is by syllable, not
    character.  Each syllable is mapped to a pair of ASCII keys.
3.  Dictionary lookup of phonetically entered words, resulting in a
    menu.
    Morphological and grammatical filtering to narrow the lookup
    results.
4.  Selection from the menu.
5.  Confirmation of the entered text.

There do exist phonetic Japanese keyboard layouts, but almost nobody
except a few professional typists use them.  Excel formulas and such
are easier to type in ASCII.  Chinese is similar; as far as I know
Chinese have no commonly used phonetic layout, they just use ASCII,
but that's just a guess based on casual conversation with Chinese grad
students.  When Koreans use Han ideographs, the process is similar.
When they don't, Hangul are composed characters but the process
entirely algorithmic.  I don't know if there are Hangul layouts in
common use but I suspect it's more common than in Japan for several
reasons.

Bottom line: about 1.3 billion people write languages where the common
practice is to type multiple ASCII characters per "native character".

Most of the rest of the world has to switch layouts to get
"self-insert-command" behavior for both ASCII and native characters.

 > Richard meant what he wrote here.

Of course he did.  The question is whether he has any experience with
using input methods other than self-insert-command.  I will bet "no",
and that his reaction is pre-judgment without enough relevant
experience.

 >  Any benefits there may be are not _practical_ ones.  The curly
 > quotes are a pain to type.

That's a fixable bug, but not in the use of curly quotes themselves,
but rather in the Emacs input system.

 > There are no practical benefits - nothing is made easier.

Wrong.  You evidently skipped over certain parts of Paul's and
Stefan's posts where they describe objective benefits they expect.
(You are welcome to disagree with them, presenting evidence to the
contrary, but not ignore them entirely as you are doing here.)  And
your deprecation of readability and beauty *in sources as well as in
help buffers* is unfair to those of us to whom it matters.  You don't
have to agree, but to me better readability and more beauty to
not-yet-programmers are quite "practical" in education.

 > In a true experiment, comment and objections would be actively
 > encouraged at an early stage.

On this subject, you can spell it "comment and objections", but in my
experience what you get is "prejudice and hysteria".  I see no reason
to change that assessment for what has happened here.  I've been
through these battles a number of times, and the comment and objection
stage is always just a waste of time and bandwidth.  Nobody ever
changes their mind based on so-called "rational argument"; the only
actual result that ever happens is that implementation is always
delayed, and often proponents give up entirely for a while.  Which
means nothing is learned.  Experiments, on the other hand, do produce
changes in position.  Sometimes on the part of proponents, sometimes
on the part of opponents.

One reason you perceive these changes to be "not experimental in
spirit" is because 90% or more of your programming life has been spent
in an environment (no VC or CVS or Subversion) where reverting a
change is practically a pain in the butt, as well as socially
difficult.  You've seen people fight reversion of their changes, and
win because they refuse and it's pragmatically hard enough that nobody
else is willing to do it.  We need to get past that and create an
environment where experiments are more frequent (and more frequently
reverted).  It's possible to do that now, although some social changes
will be needed too.