Re: A simple solution to "Upcoming loss of usability ..."

[Dmitry Gutov <dgutov@yandex.ru>]

On 06/25/2015 07:36 PM, Paul Eggert wrote:

> The proposed approach would mishandle many cases where the things being
> quoted are not typical Lisp identifiers.  E.g.:
>
> "Press ‘h’ for complete help; press ‘?’ repeatedly for a summary"
> "Make ‘funcall/apply’ form to map SOURCE-ARGLIST to TARGET-ARGLIST...."
> "... Example: ‘(ad-map-arglists '(a &rest args) '(w x y z))’ will return
> ..."

We already have a different regexp that will handle those. It's not an 
insurmountable problem either way.

> Also, the proposed approach won't easily generalize to diagnostics,
> which often quote non-identifiers like ‘%s’.

Same here.

> There's also a UI problem:
> ot would cause action-at-a-distance, because typing an apostrophe in one
> place in the buffer would visually alter a part of the line many
> characters away.

Just like typing a double-quote will make Emacs consider the rest of the 
buffer a string literal? Not that big a problem.

> Most of the advantages you mention for the proposed approach are also
> advantages of the approach in master.  With the current approach, the
> Emacs sources don't need to be changed,

Because you already changed them?

You'd still have to propagate those changes (which a sizable number of 
people expressed dislike for), to all third-party Elisp code out there.

> The main advantage of the proposed approach over the current master is
> that the source code often can still contain grave accent and apostrophe
> unmodified, even though people reading and editing the source code will
> see curved quotes.  To my mind this is more a recipe for confusion than
> anything else -- at least, I wouldn't want to inflict it on Emacs
> newcomers.

We can keep it disabled by default, if you like. Unlike the 
substitute-command-keys approach, font-lock is flexible that way.