emacs-devel
[Top][All Lists]
Advanced

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

Re: [Emacs-diffs] master 9ce1d38: Use curved quotes in core elisp diagno


From: Dmitry Gutov
Subject: Re: [Emacs-diffs] master 9ce1d38: Use curved quotes in core elisp diagnostics
Date: Wed, 19 Aug 2015 16:30:43 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0

On 08/19/2015 09:28 AM, Paul Eggert wrote:

OK, thanks for reviewing; I installed the %q patch, and followed up with
simplifications that it allows at the C level, mostly by using %qs in
formats instead of uLSQM and uRSQM.  This makes the C code easier to
read and so is a clear win.  Doing something similar in Elisp code makes
the code harder to read, though, so I held off on that.

Please don't take it as a review: I only verified that it corresponded to my proposal. But if you're not going to use the proposal as stated, and are still keeping curlies in Elisp source code, then, from where I'm standing, the new format sequence is not exactly justified.

we would have something like:

   (message "Press %<?%> or %<h%> for help, %<q%> to quit")

That looks quite nice to me.

which is harder to read and is more error-prone.

The %qs approach should be the least error-prone.

At the moment these situations are handled by ‘format’.  Simply changing
the code to use ‘substitute-command-keys’ and ASCII characters would not
work in cases like the above, because (insert (substitute-command-keys
"')")) would insert an apostrophe regardless of user text-quoting
preference.

Why? IIRC, when discussing a Lisp solution, you voted in favor of simple translation logic, one that didn't even check for pairings. substitute-command-keys could do the same.

text -> (substitute-command-keys) -> text with "escaped" text prop
      -> (translate-quotes) -> text with non-escaped straight quotes
replaces

As mentioned above it's not obvious how to get that to work; even if we
did so it'd be more complicated and error-prone, and a bit slower.
Hardly seems worth it.

As I've explained several times, we'll need this (or maybe some other, comparable) complexity to solve related issues.



reply via email to

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