bug#20926: 25.0.50; Quotation marks always display as hard quotes

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 01 Jul 2015 22:42:56 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: Eli Zaretskii <eliz@gnu.org>, 20926@debbugs.gnu.org
> 
> I reproduced the originally-reported bug and installed a patch as master commit 
> bb35a21c0e8a4b82ac04fa26a53f6ca394afbb24.

Thanks.

But what will that change do to "emacs -batch", where you earlier
arranged for use of the display table?  AFAIU, the new code will not
set up the display table in batch mode, is that correct?  If so,
messages and documentation displayed in batch mode might be illegible
on some text terminals.

> I'm not quite following the "hole in our machinery" a.k.a. "bug within the bug" 
> issue.  Perhaps a separate bug report should be filed for the other bug? 

No, it's the same issue.  The problem is that, although both
char-displayable-p and describe-char-padded-string (called by
"C-u C-x =" to display a character without risking its composition
with the neighboring ones) call the same primitive to find out whether
the character can be displayed, the latter does that dynamically at
run time, whereas the code which runs during startup and determines
whether to set up the display table does that only once.  So, for
example, if the user changes her font configuration without restarting
the session, and the quote characters change their display-ability,
"C-u C-x =" will pick that up, but the display table will not be
recomputed.

That's the "hole" I alluded to.  We need somehow to make sure that
whenever fonts are changed or the encoding of a TTY frame changes, the
display table is recomputed accordingly.

> Anyway, I think the original bug is fixed now; please give it a try.
> 
> By the way, after giving the fix a try I suggest changing your locale from 
> 'en_GB' to 'en_GB.utf8', most likely by setting the LC_ALL or LANG environment 
> variables.  I don't know why utf8 is not the default encoding, but these days 
> it's probably what you want.

How is the locale's codeset relevant here?  The issue was encountered
in a GUI session, where that should be unimportant.  Only the fonts
that are available should be important.