Upcoming loss of usability of Emacs source files and Emacs.

[Stephen J. Turnbull]

Alan Mackenzie writes:
 > 
 > Hello, Emacs.
 > 
 > First, some definitions.
 > 
 > A @dfn{working character} is a character you use in everyday life - you
 > can type it easily on your keyboard for self-insert-command, and it is
 > displayed clearly and unambiguously on your screen.

You mean like 日本語Ωα→∪S, perhaps?  Indeed, I used all ofthose
characters today in my work, and although I can't easily type them
directly for self-insert-command, it really doesn't slow me down
compared to the gymnastics it would take me to type that in TeX.
`self-insert-command' is really a red herring, IMO.

 > By contrast, a @dfn{display character}, or @dfn{non-working
 > character} is a character which isn't a working character.  To
 > insert it into a buffer, you need to type its numeric code, or use
 > (and remember) a C-x 8 ...  binding, or some other clumsy
 > workaround.

For those of us who type Japanese, math, or music, efficient input
methods are not workarounds.  They're essential, and comfortable,
tools.  I certainly have sympathy for Dorothy and Toto from Kansas who
have been getting along with a working character set that fits on a
keyboard with only one shift function and because they have never
needed input methods before don't have them, but seriously, we can and
should get past that.  Most of the world cannot type their characters
with a reasonably-sized keyboard and a single shift function (in fact,
you need at least two, don't you?) and they need to remember how to
type their working set.  I guess for German you just type AltGr + a,
o, u, or s, which is sufficiently mnemonic, but that doesn't even work
for French which has accents acute and grave on several vowels.

To summarize, yes, requiring input methods is an imposition on you.
If users like you are as many as you believe, that's a big minus and
it should be considered in the decision.  But for most of the world,
it is indeed negligible (they already know how to use the input
methods and are used to learning new characters), and sufficient
benefits would justify imposing the burden on you and others.

 > It might or might not get properly displayed on your screen.

Uh, speak for yourself.  It will be displayed properly on my screen
(note, because of Japanese I can't use the old Linux console, I have
to use fbterm anyway).  And it is possible to do that on any *old*
*cheap* hardware nowadays -- systems that *can't* be configured to
display them properly aren't "old", they're valuable antiquities that
should be registered with UNESCO.  I'm sure your system, and RMS's,
can be configured to present them properly.  If they don't, it's
because you haven't configured your system to do so.

 > Paul and I have had an extensive discussion on many of the issues
 > this raises, in the thread for bug #20707.  I am against these
 > changes for several reasons: basically, they will make our sources
 > more difficult to read

I disagree.  With well-designed Unicode fonts, in principle these
changes will make Emacs sources easier to read.  Of course it's a
matter of style, and I've resisted such changes myself for decades
because I've found the advocates to be singularly lacking in taste.
But that is no longer true.  I don't always agree with the taste of
proponents of such changes, but I'd no longer claim they have none.

 > and edit.

That is not clear, though more plausible.  For a counterexample, if
use of U+0022 is restricted to string delimiter, while it is
considered better style to use U+201C and U+201D LEFT and RIGHT DOUBLE
QUOTATION MARK for quotations embedded in strings, I would suppose
that searching for strings and marking them would become easier, both
programatically and when writing quick functions and macros on the
fly.  Editability could go either way IMHO.

 > My main objection is there is no option to turn this new "feature"
 > off.

I don't think there should be.  Despite what I wrote above, I don't
see a need for this, it is going to be a PITA for quite a few
individuals (even if they're a small fraction), so I'm basically +0 on
it.  But if we're going to do it, it's a change in content style that
has semantic implications.  It can't be passed off as a display style
option like the fringe; a compromise would be worse than either extreme.

 > Some users are going to dislike these changes, possible dislike them a
 > lot, but we are going to be forcing the curly quotes on them.

Nobody is forced to accept anything.  If users don't like the current
distributed version of Emacs, they're not limited to it.  That's the
very definition of free software.  In your case, since you choose to
maintain packages that need to be compatible with current released and
development versions, that choice is painful.  But you aren't "forced"
to do anything.

And that blade cuts both ways, as you are clearly aware because you
ask for a poll.  Just as some users dislike changes, possibly a lot,
others dislike the status quo ante, possibly a lot.  Why should a few
reactionary curmudgeons :-) hold the progressives back?

 > As far as I am aware, there has been no poll to gather and analyse
 > the views of Emacs developers on these changes, much less one for
 > Emacs users.  This is a Bad Thing.

It used to be a Bad Thing[tm].  Now, modern VCS means that such
changes can be made and reverted quickly (although not always
effortlessly or without help of developers experienced in the
software), so rather than poll, just give them what you think they
need.  If they don't like it, you revert.  That method provides far
more accurate assessments of user sentiment than polling in advance,
and is less costly (unless you're stupid enough to make such a change
in a late beta).

Of course the proponents have to be cooperative.  I know that Paul has
a reasonably high opinion of his own opinions ;-), but I've also seen
him revert patches for reasons of "general user taste", and with very
little backtalk, on request.  I see no reason why the "commit and if
necessary revert" process won't work as described above in this case.

Regards,
Steve