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

[Paul Eggert <eggert@cs.ucla.edu>]

Dmitry Gutov wrote:
>> "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.

Perhaps some complex regular expression would work most of the time.  We'd have 
to see.  However, its complexity will make its behavior hard to document, and it 
will likely lead to counterintuitive display of source code on occasion.  It's a 
minor thing to get a color wrong; it's a bigger deal to display the wrong 
character.  The resulting problems are likely not to be worth the aggravation.

>> 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.

As I said, action-at-a-distance is not a fatal objection.  But yes, that 
behavior of double-quote is objectionable, and I wish that Emacs didn't do it. 
I hope we don't need to add more glitches like it.

> 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.

Third-party code doesn't need to change.  It'll still work reasonably well.

>> 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.

Sorry, I don't understand this remark.  Both approaches allow for defaults, and 
for behavior to be disabled by default, so neither has an advantage in that respect.