bug#21780: 25.0.50; Saving *Help* results in bad encoding because of curly quotes

[Drew Adams <drew.adams@oracle.com>]

> > emacs -Q
> > M-x load-library isearch.el
> > C-h f isearch-forward
> > In buffer *Help*: C-x C-w foo.txt
> >
> > You get a coding-system warning.  I tried saving it as utf-8 and as raw
> > text.
> >
> > In both cases, when I open that file in a new Emacs session, I see octal
> > escapes where there were curly quotes.
> 
> Thanks, I fixed the first part of this: Emacs should no longer ask
> annoying questions when you save help buffers with curved quotes.
> 
> The second part, which happens when visiting the saved file, is not a
> bug: you need to specify the encoding of files when visiting them in
> locales whose default encoding is different.  (Actually, I expect this
> to work automatically for you, at least in "emacs -Q", but that
> doesn't happen in every locale.)

I guess I should interpret this as meaning that the bug is fixed (?).

But I don't understand the second part.  What do I need to change, as
a user, to get this to work as I would expect?

In Emacs, before saving, the buffer looks fine.  When visiting the
resulting file it does not look right - it is unreadable.  There are
3 octal escapes for each opening curly quote and 3 of them for each
closing curly quote.  That can amount to quite a lot of noise.

Do I need to save the buffer using some other encoding?  If so, which?
Emacs proposed two encodings (one of which was raw text, which I tried;
and I tried also utf-8, which I would have thought would show curly
quotes OK.

I would think that Emacs would DTRT when opening the file, based on
the encoding used to save it.  Should users really need to do something
special each time they visit the file?  They've never had to do this
before, for basic, common *Help* output.

This still seems like a regression to me, as there is no such
annoyance in Emacs 24.5 or prior.  Then, Emacs did not use curly
quotes for `describe-*' command output, and saved *Help* buffers
were readable from the outset.

If readers have to jump through hoops (e.g. changing "locales"),
and there is no good fix for this regression in behavior, then I'd
suggest that maybe `describe-*' commands should not use curly quotes.

[Or could this perhaps be a font problem?  Might the default font
(e.g. on MS Windows) just need to be changed?]