[Top][All Lists]

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

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

From: Kaushal
Subject: Re: Upcoming loss of usability of Emacs source files and Emacs.
Date: Mon, 15 Jun 2015 11:30:53 -0400

+1 for what Alan has to say.
+1 for keeping ` and ' for greppability as Oleh mentioned
+1 to what Drew said; seeing commits related to curly braces is not very exciting

Kaushal Modi

On Mon, Jun 15, 2015 at 11:23 AM, Drew Adams <address@hidden> wrote:
> 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.

Of course not.  When was the last time you saw such a poll? ;-)

> This is a Bad Thing.


> What do people think?

I've already made my position clear about this in the bug list.
But I'll state it one more time.

`...' is a very *good* way to set off inline symbols and other
code phrases from surrounding non-code text.  Those who think
it is somehow just an odd and imperfect, old-fashioned form of
*quoting* are sadly mistaken.  That is not what it is about.

'...' is used in ordinary English text, along with "...", for
normal quotation.  As a text editor (among other things), Emacs
should not interfere with this usage or make it difficult for
users or programs to parse it and manipulate it, by piling on
an alternative interpretation.  (Occam oblige.)

What is needed in any doc about software is a way to clearly
set off inline code phrases from surrounding, non-code text.
This demarking constitutes metadata that is different from
ordinary-text quoting.

When structured doc or markup is used, this is typically
accomplished using metadata that is provided by wrapping the
code phrases in XML (or similar) elements/markup:

In Emacs, we want, if possible, a simple mechanism that lets
the text that contains the metadata (the "markup" text) to also
act as the text that the user interacts with directly - search
etc., but without the distraction of interacting with obvious
markup (<code> etc.).

`...' is simply an ingenious abbreviation for what is usually
handled more verbosely using constructs such as <code>...</code>.

As Alan points out, we want the metadata for this to be easy
and quick to type, and not to interfere with either appearance
or handling by program (including, but not limited to, Lisp).

For all Emacs purposes I am aware of `...' is a very *good*
invention.  It is a reasonable compromise (yes, like anything
else, it is not unambiguous in all contexts).  And it has
proven its worth in Emacs for 3 decades.

That one person (plus our dear leader, apparently) thinks
`...' is too "ugly" or too 1980s for his own use should not
be a reason for Emacs to continue down the rabbit hole it
has apparently been overzealously pushed into.

The argument that ` and ' used to look OK back in the 80s,
but fonts have changed so they are no longer symmetric,
really misses the point.

A delimiting pair of chars that is not confused with other
uses ([], (), {}, <>, '', "",...) is what is needed, and
`...' fits the bill well.  (Some other contexts use `` or '',
but like "", these have an obvious disadvantage.  Still, even
they would be preferable to '...'.)

This change, whether implemented (a) only for rendering
(appearance) or (b) at the base - actually using '...' in
the underlying text, is altogether misguided, IMHO.

Whether those originally responsible for `...' were aware of
all of its advantages as a means of setting off inline code,
I don't know.  But I thank them for it.  I hope that Emacs
will eventually come to its senses about this and appreciate
what a great gift `...' really is.

Instead of being ashamed of `...' as a black sheep, the Emacs
family should embrace it and be proud.  Especially, it should
understand how truly useful it is.  '...' for inline code is
a misguided, ugly hack, and in the long run not very workable.

Emacs still has important and exciting things to work on and
invent.  The '...' crusade is not one of them, IMHO.

reply via email to

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