|
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 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.
[Prev in Thread] | Current Thread | [Next in Thread] |