bug#21588: 25.0.50: Single quotes becoming curvy quotes in message function

[Kaushal Modi <kaushal.modi@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4203 bytes --]

tl;dr: Thanks Paul, this is awesome!

---

> The GNU coding standards were changed a while ago to recommend against
grave quoting in diagnostics and many GNU applications have already changed
(e.g., coreutils, GCC).  Although Emacs has been one of the holdouts, now
is as good a time as any to make the move.

I was unaware of that. Thanks for letting me know. For future reference for
anyone else, you can learn more about this "C-h i g (standards) Quote
Characters".

> Thanks, done in the attached patch, which I just installed in the master
branch.

Thanks! For future reference for anyone else, these clarifications can be
viewed in the following info nodes:

- (elisp) Displaying Messages
- (elisp) Signaling Errors

> That discussion was intended to be about text files, so I added a phrase
to that effect in the attached patch.  This should help resolve the seeming
contradiction.

- (emacs) Quotation Marks

> Any heuristics will go awry sometimes so we need some way to override the
heuristics; and once we have such an override, there is a real benefit to
keeping the heuristics simple.

I agree to that argument.

Thanks for fixing the quotes in string formats in few other .el files.

In summary:
- I agree with you now that the current default value of text-quoting-style
is good.
- I will stick to that default and find places where the quoting needs to
be updated from 'Hey' to `Hey'.
- I will submit patches/pull requests wherever I find such instances within
emacs or in external packages.

Thank you for all your time and effort in making this clear and fixing up
the documentation and .el files.



--
Kaushal Modi

On Fri, Oct 2, 2015 at 2:51 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:

> On 09/30/2015 08:54 PM, Kaushal Modi wrote:
> > - Can the default be changed to 'grave?
>
> The GNU coding standards were changed a while ago to recommend against
> grave quoting in diagnostics and many GNU applications have already changed
> (e.g., coreutils, GCC).  Although Emacs has been one of the holdouts, now
> is as good a time as any to make the move.
>
> we need to update the documentation that warns the user to use the correct
>> style.
>>
>
> Thanks, done in the attached patch, which I just installed in the master
> branch.
>
> > it is mentioned that typewriter quotes are simple and portable.
>
> That discussion was intended to be about text files, so I added a phrase
> to that effect in the attached patch.  This should help resolve the seeming
> contradiction.
>
> If we want to keep the default of text-quoting-style as nil (or 'curve),
>> more logic needs to be added that decides whether left curly quote or right
>> curly quote should be used, which might have some performance impact as we
>> then need to check what the previous character is, what the next character
>> is, etc to decide if the current apostrophe needs to be replaced with a
>> left or a right quote.
>>
>
> It’s not a significant performance impact.  It’s more a hassle of
> documenting a more-complex approach.  That is partly why I gave up on such
> an approach after implementing it, and went with the simpler approach that
> is in Emacs master now.
>
> > CASE 1: 'Hey' -> ‘Hey’
> > CASE 2: it's awesome -> it’s awesome
> > CASE 3: my sisters' weddings -> my sisters’ weddings
> > CASE 4: He said 'It's awesome!' -> He said ‘It’s awesome!’
>
> ‘message’ already does cases 2 and 3 that way, as well as the 2nd
> apostrophe in case 4.  The remaining cases are quite rare in Emacs
> diagnostics, as the Emacs style uses directed quotes when single-quoting.
>
> If there's a non-space character before the apostrophe, replace it with
>> right quote, else use left quote.
>>
>
> That would mishandle common English phrases like “'60s pop culture” and
> “rock 'n' roll”.  (These phrases don’t occur in Emacs diagnostics either,
> but as long as we’re being pedantic....)  Any heuristics will go awry
> sometimes so we need some way to override the heuristics; and once we have
> such an override, there is a real benefit to keeping the heuristics simple.
>

[-- Attachment #2: Type: text/html, Size: 9313 bytes --]