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

[Dmitry Gutov <dgutov@yandex.ru>]

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.