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

[Alan Mackenzie <acm@muc.de>]

Hello, Paul.

On Thu, Jun 25, 2015 at 09:36:53AM -0700, Paul Eggert wrote:
> Oleh Krehel wrote:
> > (font-lock-add-keywords
> >   'emacs-lisp-mode
> >   '(("\\(`\\)\\([a-zA-Z-0-9]+\\)\\('\\)"

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

I think there will be several of these cases rather than many.

> Also, the proposed approach won't easily generalize to diagnostics, which often 
> quote non-identifiers like ‘%s’.  There's also a UI problem: it 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. 
> (Action-at-a-distance is not a fatal objection, but it is better to avoid it 
> when possible.)

It's not a problem at all.  Font lock does it all the time.  For
example, just type in "save-excursion" a letter at a time.  Only on
typing the "n" does the whole symbol get fontified.

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

they've already been massively changed.  

> .... quotes are just as easy to input (in Electric Quote mode), ....

This is an unpleasant workaround.  It violates "what you type is what
you get".

> .... terminal and copy-pasting work, and quotes are markup.

Which is true, for certain values of "terminal" and "copy-pasting".

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

The main advantage is that non-working characters, the curly quotes,
would not take a central role in Emacs Lisp source code, together with
all the workarounds of questionable taste that they necessitate.  It is
solely these non-working characters which I take exception to, and I
think the same is true of several others objecting to these changes.

How about considering these other approaches, in which non-working
characters would not be proliferated through the strings in our source
code?

-- 
Alan Mackenzie (Nuremberg, Germany).