Re: per-buffer language environments

[Werner LEMBERG]

> I wasn't talking about any bugs at all.  Werner suggested to add a
> new _feature_; I was talking about what that feature should and
> shouldn't include.

Perhaps it makes sense to provide typical user cases instead of
theorizing a priori.  Hopefully, others provide real-life scenarios
too.

  My case:

    file language: Chinese or Japanese or Korean
    file encoding: UTF-8 (or any other flavour of Unicode)

    Wish:
      Emacs should select a proper font based on a file language tag.
      The fonts should be specified by the user, to be configured as a
      preference list in `.emacs'.

    Reason:
      It is not possible to automatically decide whether a given font
      like SimSun is really suitable for a given language; this
      concept is missing in the OpenType specification, contrary to,
      say, CID-keyed fonts.  A hint might be the presence of a
      specific script and language tag in the font's OpenType tables
      (`HANI' and `CHN', respectively, for SimSun), but there are many
      TrueType fonts which don't have advanced OpenType features.
      Since SimSun contains Katakana, Hiragana, and CJK glyphs – this
      might be deduced from the OS/2 table, and FontConfig checks that
      also – it *can* be used for Japanese, but it doesn't *suit*.

      This problem is really important for CJK fonts, however, even
      European languages can be affected.  For example, the right way
      in Romanian is to write `ş' (s with cedilla), but it should be
      displayed as `ș' (s with comma below).  Recent OpenType fonts
      often contain proper language tags so that a language specific
      mapping can be done, but many, many Type 1 fonts don't; they
      contain the glyph name `scedilla', but the real glyph displayed
      is s with comma below.


    Werner