*curly quotes (not braces) -- Kaushal Modi On Mon, Jun 15, 2015 at 11:30 AM, Kaushal wrote: > +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 > 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. >> >> Yes. >> >> > 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 ( etc.). >> >> `...' is simply an ingenious abbreviation for what is usually >> handled more verbosely using constructs such as .... >> >> 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. >> >> >