[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: Dmitry Gutov
Subject: Re: A simple solution to "Upcoming loss of usability ..."
Date: Thu, 25 Jun 2015 21:32:14 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0

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

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

reply via email to

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