[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A simple solution to "Upcoming loss of usability ..."
From: |
Alan Mackenzie |
Subject: |
Re: A simple solution to "Upcoming loss of usability ..." |
Date: |
Thu, 25 Jun 2015 20:58:44 +0000 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
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).
Re: A simple solution to "Upcoming loss of usability ...",
Alan Mackenzie <=