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

[Drew Adams]

> That wasn't really meant as a suggestion.  I just wanted to ask why
> not use some extremely rare paired characters if unambiguity is the
> main point and we have some convenient input method anyhow.  That
> simply typing a key which has the exact letter on it is even better
> is obvious.

FWIW, a week or so ago I almost posed the same rhetorical question.

I was going to use this pair as an example [1]:

◄foobar►    BLACK (LEFT|RIGHT)-POINTING POINTER

Here it is, used for sexps and key descriptions we might show
in Lisp docs/help:

◄foobar►                = `foobar'
◄"foobar toto"►         = `"foobar toto"'
◄(foobar toto 42)►      = `(foobar toto 42)'
◄`(setq foo ',(bar t))► = ``(setq foo ',(bar t))'
◄M-x apropos-char►      = `M-x apropos-char'
◄C-x C-c►               = `C-x C-c'

Here are the same sexps shown with curly quotes:

‘foobar’                = `foobar'
‘"foobar toto"’         = `"foobar toto"'
‘(foobar toto 42)’      = `(foobar toto 42)'
‘`(setq foo ',(bar t))’ = ``(setq foo ',(bar t))'
‘M-x apropos-char’      = `M-x apropos-char'
‘C-x C-c’               = `C-x C-c'

Tassilo's point here, I think, and at least my point here, is
that this is *not at all about quotation* in the usual sense.
There is no reason to use quotation marks of any kind, which
can mess with their ordinary use as, well, er, um, quotation
marks.

Those who make claims to the effect that 99.999% of the world
uses curly quotes miss the point entirely, IMHO.  Of course
they do!  (Well, maybe not five 9s.)  And so do I.

But they use them for text *quotation*.  That's not what we
use `...' for.  We use it to set off code phrases from
surrounding text that talks about them.  It is our equivalent
of markup such as <code>...</code> and <kbd>...</kbd>.

Yes, of course, *any* mention instead of use is a form of
quotation in the larger, logical sense.  Quoting means pushing
up a metalanguage level, and vice versa.

But that's really beside the point here.  We have a context
where we want to distinguish code from text, including from
text quotations.  Emacs is, among other things, a general
text editor.

And we would like, if possible, the external form to be the
same as the internal form.  If we can avoid it, we would
prefer not to have <code>...</code> or similar be what is
written in a file and have that just be rendered using
highlighting or a special font - which is the typical
treatment.  We could live with that approach, no doubt, but
it is not what we would prefer.

Why?  Because we want to act on the internal form directly,
including interactively, in ways that other contexts do not,
or that do so only inelegantly, clumsily, or in a restricted
way.  We are spoiled, I guess, having had the simplicity of
Lisp syntax and simple `...' sexp mention for decades now.

It's true that you can use a good XML editor to both render
XML-based documents in a formatted way and let you search for
text that is within (or without) <code>...</code> elements.
But the UIs they provide, including for operations such as
search-&-replace and other modifications, are far too clunky
and limited for what we do.

Can we do what others do, having a different internal
representation from what gets rendered?  Of course.  And some
are arguing that that's the approach to take wrt curly quotes,
to paper over some of the warts.

Do we want to have to fiddle with two different levels that
way: internal vs rendered representations?  Of course not,
if we can reasonably avoid it.

Emacs is about Lisp for a reason.  And Lisp is about
representing programs and data the same way - for a reason.
If we can avoid such a translation and flipping between
representations, we would prefer it in general - direct
action, WYSIWYG.

So why do I say (as Tassilo also suggests, I think) that
◄foobar► is only a *rhetorical* suggestion?  Why don't I
really propose such a solution?  (And why didn't I bother
to mention it a week ago?)

For all of the Emacsy reasons people have so far given that
explain why curly quotes are a bad idea: trouble inserting,
searching, etc.  That is, for all of the _other_ reasons,
besides the reason that this is not about quotation.

What we should look for is both (1) a mirror pair of chars
that is not confusable with other uses of the same and
(2) a pair of chars that is simple to insert, search, etc. -
in general, simple to use in a rudimentary, plain-text
(perhaps even ASCII) context.

Criterion #1 rules out pairs such as curly quotes and
guillemets of all stripes, as well as [], (), {}, <> etc.

Criterion #2 rules out most non-ASCII Unicode chars.

(There is a third criterion that makes life easier: a pair
of *different* chars, not just using the same char twice:
'...', `...`, |...|, \...\, /.../, etc.  This is maybe not
essential, but it is handy.)

These two criteria work against each other to some extent.

To fit #1 we want a pair that is *rarely used* in typical
contexts, including documentation and other ordinary text
contexts (which make use of quotation).  But to fit #2 we
want a pair that must not be rare, because rare chars are
not easily typed, searched for, and otherwise used in even
a rudimentary plain-text context.

Maybe someone has a truly brilliant idea for this?

Note that we are in this dilemma, with these opposing
criteria, precisely because we have (till now) opted to
not use two different representations: internal and
external.  Sacrificing that simplicity and going to two
representations is one way to go, I guess, but it is not
one I favor.

`...' is the most brilliant idea I've seen so far for this.
Satisifies all of the criteria.  Simple; straightforward;
just works.  It ain't broke, and we shouldn't fix it.

But it has *one* strike against it: a few people find it
“ugly”, ‟ugly”, "ugly", ‘ugly’, ‟ugly„, 〝ugly〞, ❝ugly❞,
❛ugly❜, «ugly» !

Some of us don't find it so, but yes, beauty is in the eye
of the beholder.  Why someone's beauty concerns should trump
usefulness I don't know.  Mais on n'arrete pas le progres...

---
[1] Believe it or not, I scanned all of the Unicode chars for
a good example - a pair that works in terms of char width (at
least for the fonts I tried), one that has no particular other
use with which this use might be confused, and one that is not
easily confused with other pairs (e.g. various forms of brackets).