[Top][All Lists]

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

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

From: Paul Eggert
Subject: Re: A simple solution to "Upcoming loss of usability ..."
Date: Thu, 25 Jun 2015 15:17:05 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

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

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.

reply via email to

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