bug#24603: [PATCHv5 07/11] Introduce ‘buffer-language’ buffer-locar variable

[Eli Zaretskii]

> From: Michal Nazarewicz <mina86@mina86.com>
> Date: Thu,  9 Mar 2017 22:51:46 +0100
> 
> diff --git a/lisp/international/mule-cmds.el b/lisp/international/mule-cmds.el
> index bdba8eeb112..d883e8c2298 100644
> --- a/lisp/international/mule-cmds.el
> +++ b/lisp/international/mule-cmds.el
> @@ -2601,7 +2601,7 @@ set-locale-environment
>       (setq system-messages-locale locale)
>       (setq system-time-locale locale))
>  
> -      (if (string-match "^[a-z][a-z]" locale)
> +      (when (string-match "^[a-z][a-z]" locale)
>            ;; The value of 'current-iso639-language' is matched against
>            ;; the ':lang' property of font-spec objects when selecting
>            ;; and prioritizing available fonts for displaying
> @@ -2613,7 +2613,11 @@ set-locale-environment
>                  ;; match mentioned above uses memq, and ':lang'
>                  ;; properties have lower-case values, the letter-case
>                  ;; must match exactly.
> -                (intern (downcase (match-string 0 locale))))))
> +                (intern (downcase (match-string 0 locale))))
> +
> +          ;; ‘buffer-language’ is used to identify language buffer is in for 
> the
> +          ;; purpose of performing language-specific operations.
> +          (setq-default buffer-language locale)))

This make buffer-language's value include the locale's codeset, which
is unnecessary and might get in the way later.  I think we should
remove the codeset part, if present.

In addition, there's the case of Windows, where languages use a
different, 3-letter notation (e.g., "ENU" instead of the Posix
"en_US").  So I think we need a function to generate the portable
language name from the locale, which will need to use a database of
conversions for Windows (this could be added later, if you like, but
we need at least a FIXME comment to that effect).

> +  bset_language (&buffer_defaults, Qnil);

It's hard to see if this default is TRT, since the practical meaning
of nil here is not yet clear, not even after reading the doc string of
buffer-language.  The nil value is of course okay for special casing
rules, but you propose this feature for more than that.  For example,
for spell-checking purposes, it is not clear what nil means.

I have a higher-level comments on this feature, which I will post
elsewhere.

Last, but not least: can we have some tests for this?

Thanks.