set-locale-environement: strange default detection

set-locale-environement: strange default detection

[Sascha Wilde]

Hi *,

a friend of mine (unfortunately a vim user, but a nice guy otherwise),
tried emacs on Gnu/Linux and was surprised that `C-h t' presented him
the German version of the tutorial.

His i18n environment is:
LANG=en_US
LC_CTYPE=de_DE@euro
LC_NUMERIC="en_US"
LC_TIME="en_US"
LC_COLLATE=POSIX
LC_MONETARY="en_US"
LC_MESSAGES="en_US"
LC_PAPER="en_US"
LC_NAME="en_US"
LC_ADDRESS="en_US"
LC_TELEPHONE="en_US"
LC_MEASUREMENT="en_US"
LC_IDENTIFICATION="en_US"
LC_ALL=

so it should be clear, that, also he wants to be able to handle German
texts properly, he wants his user interfaces in English.

But set-locale-environment tests LC_CTYPE _before_ LANG, from the
doc string: 

  If LOCALE-NAME is nil, its value is taken from the environment
  variables LC_ALL, LC_CTYPE and LANG (the first one that is set).

Which IMO is an bug.  (LC_CTYPE is not supposed to be used as an
indicator for the ui language at all, but if it is used, it should be
used as an last resort.)

cheers
sascha
-- 
"Anyone who slaps a 'this page is best viewed with Browser X' label on a Web 
page appears to be yearning for the bad old days, before the Web, when you had 
very little chance of reading a document written on another computer, another 
word processor, or another network." -- Tim Berners-Lee, July 1996

Re: set-locale-environement: strange default detection

[David Kastrup]

Sascha Wilde <wilde@sha-bang.de> writes:

> a friend of mine (unfortunately a vim user, but a nice guy otherwise),
> tried emacs on Gnu/Linux and was surprised that `C-h t' presented him
> the German version of the tutorial.
>
> His i18n environment is:
> LANG=en_US
> LC_CTYPE=de_DE@euro
> LC_NUMERIC="en_US"
> LC_TIME="en_US"
> LC_COLLATE=POSIX
> LC_MONETARY="en_US"
> LC_MESSAGES="en_US"
> LC_PAPER="en_US"
> LC_NAME="en_US"
> LC_ADDRESS="en_US"
> LC_TELEPHONE="en_US"
> LC_MEASUREMENT="en_US"
> LC_IDENTIFICATION="en_US"
> LC_ALL=
>
> so it should be clear, that, also he wants to be able to handle German
> texts properly, he wants his user interfaces in English.
>
> But set-locale-environment tests LC_CTYPE _before_ LANG, from the
> doc string: 
>
>   If LOCALE-NAME is nil, its value is taken from the environment
>   variables LC_ALL, LC_CTYPE and LANG (the first one that is set).
>
> Which IMO is an bug.  (LC_CTYPE is not supposed to be used as an
> indicator for the ui language at all, but if it is used, it should be
> used as an last resort.)

The problem is that we don't have finegrained support.  For the
purpose of talking to the user, LC_MESSAGES is relevant.  But Emacs so
rarely has the opportunity to talk anything but English to the user
that we simply have no reasonable interface into this for now.

-- 
David Kastrup

Re: set-locale-environement: strange default detection

[Sascha Wilde]

David Kastrup <dak@gnu.org> wrote:
> Sascha Wilde <wilde@sha-bang.de> writes:

>> a friend of mine (unfortunately a vim user, but a nice guy otherwise),
>> tried emacs on Gnu/Linux and was surprised that `C-h t' presented him
>> the German version of the tutorial.
[...]
> The problem is that we don't have finegrained support.  For the
> purpose of talking to the user, LC_MESSAGES is relevant.  But Emacs so
> rarely has the opportunity to talk anything but English to the user
> that we simply have no reasonable interface into this for now.

So maybe we should check for LANG, LC_ALL and maybe LC_MESSAGES in
tutorial.el itself.

Displaying the tutorial (one of the first things a new user sees from
Emacs) in an unexpected language, ignoring the standard i18n
environment, leaves an bad first impression.

sascha
-- 
Sascha Wilde 
- no sig today... sorry!

Re: set-locale-environement: strange default detection

[David Kastrup]

Sascha Wilde <wilde@sha-bang.de> writes:

> David Kastrup <dak@gnu.org> wrote:
>> Sascha Wilde <wilde@sha-bang.de> writes:
>
>>> a friend of mine (unfortunately a vim user, but a nice guy otherwise),
>>> tried emacs on Gnu/Linux and was surprised that `C-h t' presented him
>>> the German version of the tutorial.
> [...]
>> The problem is that we don't have finegrained support.  For the
>> purpose of talking to the user, LC_MESSAGES is relevant.  But Emacs so
>> rarely has the opportunity to talk anything but English to the user
>> that we simply have no reasonable interface into this for now.
>
> So maybe we should check for LANG, LC_ALL and maybe LC_MESSAGES in
> tutorial.el itself.

Possibly.  I am not sure whether environment variables tell the whole
story, and in a readable way (there are locale system calls, too), but
they would probably cover 90% of the cases.

-- 
David Kastrup

Re: set-locale-environement: strange default detection

[Jan Djärv]

David Kastrup skrev:
> Sascha Wilde <wilde@sha-bang.de> writes:
> 
>> David Kastrup <dak@gnu.org> wrote:
>>> Sascha Wilde <wilde@sha-bang.de> writes:
>>>> a friend of mine (unfortunately a vim user, but a nice guy otherwise),
>>>> tried emacs on Gnu/Linux and was surprised that `C-h t' presented him
>>>> the German version of the tutorial.
>> [...]
>>> The problem is that we don't have finegrained support.  For the
>>> purpose of talking to the user, LC_MESSAGES is relevant.  But Emacs so
>>> rarely has the opportunity to talk anything but English to the user
>>> that we simply have no reasonable interface into this for now.
>> So maybe we should check for LANG, LC_ALL and maybe LC_MESSAGES in
>> tutorial.el itself.
> 
> Possibly.  I am not sure whether environment variables tell the whole
> story, and in a readable way (there are locale system calls, too), but
> they would probably cover 90% of the cases.
> 

The locale man page says the order should be LC_ALL, LC_MESSAGES, LANG:

       1.     If there is a non-null environment variable LC_ALL, the value of
              LC_ALL is used.

       2.     If an environment variable with the same name as one of the cat‐
              egories above exists and is non-null, its value is used for that
              category.

       3.     If there is a non-null environment variable LANG, the  value  of
              LANG is used.



	Jan D.

Re: set-locale-environement: strange default detection

[Sascha Wilde]

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

David Kastrup <dak@gnu.org> wrote:

> Sascha Wilde <wilde@sha-bang.de> writes:
>
>> David Kastrup <dak@gnu.org> wrote:
>>> Sascha Wilde <wilde@sha-bang.de> writes:
>>
>>>> a friend of mine (unfortunately a vim user, but a nice guy otherwise),
>>>> tried emacs on Gnu/Linux and was surprised that `C-h t' presented him
>>>> the German version of the tutorial.
>> [...]
[...]
>> So maybe we should check for LANG, LC_ALL and maybe LC_MESSAGES in
>> tutorial.el itself.
>
> Possibly.  I am not sure whether environment variables tell the whole
> story, and in a readable way (there are locale system calls, too), but
> they would probably cover 90% of the cases.

I attached a rough patch, which solves the problem at least on
POSIX-like systems:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: emacs-tutorial-lang.patch --]
[-- Type: text/x-patch, Size: 2296 bytes --]

diff -c -L /vol1/opt/cvs-emacs-sarge/share/emacs/22.1.50/lisp/tutorial.el.gz -L /vol1/opt/src/emacs-hg-sarge/lisp/tutorial.el /tmp/jka-com32572F4r /vol1/opt/src/emacs-hg-sarge/lisp/tutorial.el
*** /vol1/opt/cvs-emacs-sarge/share/emacs/22.1.50/lisp/tutorial.el.gz
--- /vol1/opt/src/emacs-hg-sarge/lisp/tutorial.el
***************
*** 621,626 ****
--- 621,636 ----
  					      face tutorial-warning-face
  					      read-only t)))))))))))
  
+ (defun tutorial-get-language ()
+   "Use LC_ALL, LC_MESSAGES, LANG in turn to determine language to use.
+ This is more reliable then current-language-environment, which is not
+ intended to chose the language used for messages and documentation."
+   (let ((locale "") (vars '("LC_ALL" "LC_MESSAGES" "LANG")))
+     (while (and vars
+ 		(= 0 (length locale))) ; nil or empty string
+       (setq locale (getenv (pop vars))))
+     (locale-name-match locale locale-language-names)))
+ 
  (defun tutorial--saved-dir ()
    "Directory to which tutorials are saved."
    (expand-file-name "tutorial" user-emacs-directory))
***************
*** 766,774 ****
                         (add-hook 'minibuffer-setup-hook
                                   'minibuffer-completion-help)
                         (read-language-name 'tutorial "Language: " "English"))
!                    (if (get-language-info current-language-environment 'tutorial)
!                        current-language-environment
!                      "English")))
             (filename (get-language-info lang 'tutorial))
             ;; Choose a buffer name including the language so that
             ;; several languages can be tested simultaneously:
--- 776,785 ----
                         (add-hook 'minibuffer-setup-hook
                                   'minibuffer-completion-help)
                         (read-language-name 'tutorial "Language: " "English"))
!                    (or (tutorial-get-language)
! 		       (if (get-language-info current-language-environment 'tutorial)
! 			   current-language-environment
! 			 "English"))))
             (filename (get-language-info lang 'tutorial))
             ;; Choose a buffer name including the language so that
             ;; several languages can be tested simultaneously:

Diff finished.  Wed Jul 18 14:23:30 2007

[-- Attachment #3: Type: text/plain, Size: 80 bytes --]


sascha
-- 
Sascha Wilde
Nothing is fool-proof to a sufficiently talented fool.

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: set-locale-environement: strange default detection

[Reiner Steib]

On Wed, Jul 18 2007, Sascha Wilde wrote:

> LANG=en_US
> LC_CTYPE=de_DE@euro
[...]
> so it should be clear, that, also he wants to be able to handle German
> texts properly, he wants his user interfaces in English.

JFTR, I reported the same problem before:

,----[ http://thread.gmane.org/E1Gn4h0-00057g-Uh%40fencepost.gnu.org ]
| From: Reiner Steib
| To: emacs-pretest-bug <at> gnu.org
| Date: Wed, 22 Nov 2006 09:36:52 +0100
| Subject: language environment should not be derived from LC_CTYPE
`----

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: set-locale-environement: strange default detection

[David Kastrup]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> On Wed, Jul 18 2007, Sascha Wilde wrote:
>
>> LANG=en_US
>> LC_CTYPE=de_DE@euro
> [...]
>> so it should be clear, that, also he wants to be able to handle German
>> texts properly, he wants his user interfaces in English.
>
> JFTR, I reported the same problem before:
>
> ,----[ http://thread.gmane.org/E1Gn4h0-00057g-Uh%40fencepost.gnu.org ]
> | From: Reiner Steib
> | To: emacs-pretest-bug <at> gnu.org
> | Date: Wed, 22 Nov 2006 09:36:52 +0100
> | Subject: language environment should not be derived from LC_CTYPE
> `----

That is not the same problem.  "language-environment" entails much
more than "which language should the computer pick for talking to the
human?".  LC_CTYPE should definitely determine the preferred
encodings.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: set-locale-environement: strange default detection

[Sascha Wilde]

David Kastrup <dak@gnu.org> wrote:

> Reiner Steib <reinersteib+gmane@imap.cc> writes:
>
>> On Wed, Jul 18 2007, Sascha Wilde wrote:
>>
>>> LANG=en_US
>>> LC_CTYPE=de_DE@euro
>> [...]
>>> so it should be clear, that, also he wants to be able to handle German
>>> texts properly, he wants his user interfaces in English.
>>
>> JFTR, I reported the same problem before:
>>
>> ,----[ http://thread.gmane.org/E1Gn4h0-00057g-Uh%40fencepost.gnu.org ]
>> | From: Reiner Steib
>> | To: emacs-pretest-bug <at> gnu.org
>> | Date: Wed, 22 Nov 2006 09:36:52 +0100
>> | Subject: language environment should not be derived from LC_CTYPE
>> `----
>
> That is not the same problem.  "language-environment" entails much
> more than "which language should the computer pick for talking to the
> human?".

s/much more/something different/

> LC_CTYPE should definitely determine the preferred encodings.

I agree.  But then language-environment definitely shouldn't be used
to determine the language for documentation/ui/anythinglikethat...

So, what about the idea I sketched in my patch?

sascha
-- 
Sascha Wilde : "There are 10 types of people in the world. 
             : Those who understand binary and those who don't."

Re: set-locale-environement: strange default detection

[David Kastrup]

Sascha Wilde <wilde@sha-bang.de> writes:

> David Kastrup <dak@gnu.org> wrote:
>
>> LC_CTYPE should definitely determine the preferred encodings.
>
> I agree.  But then language-environment definitely shouldn't be used
> to determine the language for documentation/ui/anythinglikethat...
>
> So, what about the idea I sketched in my patch?

The proper fix would be to have something more fine-grained than
language-environment inside of Emacs.

Until such a time, your fix appeared like the right thing to do at
that junction to me.  Your patch (I am going my memory here) has the
disadvantage that it might look up the empty string as a language
explicitly, expecting it to turn up nil.  That's sort of ugly.

-- 
David Kastrup

Re: set-locale-environement: strange default detection

[Reiner Steib]

On Wed, Jul 18 2007, David Kastrup wrote:

> Reiner Steib <reinersteib+gmane@imap.cc> writes:
>> On Wed, Jul 18 2007, Sascha Wilde wrote:
>>> LANG=en_US
>>> LC_CTYPE=de_DE@euro
>> [...]
>>> so it should be clear, that, also he wants to be able to handle German
>>> texts properly, he wants his user interfaces in English.
>>
>> JFTR, I reported the same problem before:
>>
>> ,----[ http://thread.gmane.org/E1Gn4h0-00057g-Uh%40fencepost.gnu.org ]
>> | From: Reiner Steib
>> | To: emacs-pretest-bug <at> gnu.org
>> | Date: Wed, 22 Nov 2006 09:36:52 +0100
>> | Subject: language environment should not be derived from LC_CTYPE
>> `----
>
> That is not the same problem.  "language-environment" entails much
> more than "which language should the computer pick for talking to the
> human?".  LC_CTYPE should definitely determine the preferred encodings.

Maybe the choice of the subject was not the best one, but the problem
described there primarily is about the language of the tutorial.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Better language detection for tutorial (was: set-locale-environement: strange default detection)

[Sascha Wilde]

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

David Kastrup <dak@gnu.org> wrote:
> Sascha Wilde <wilde@sha-bang.de> writes:
>> So, what about the idea I sketched in my patch?
>
> The proper fix would be to have something more fine-grained than
> language-environment inside of Emacs.
>
> Until such a time, your fix appeared like the right thing to do at
> that junction to me.  Your patch (I am going my memory here) has the
> disadvantage that it might look up the empty string as a language
> explicitly, expecting it to turn up nil.  That's sort of ugly.

Here a revised version of the patch:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: emacs-tutorial-lang.patch --]
[-- Type: text/x-patch, Size: 2366 bytes --]

diff -c /usr/local/hg/emacs-hg/lisp/tutorial.el /home/wilde/src/emacs-hg-work/lisp/tutorial.el
*** /usr/local/hg/emacs-hg/lisp/tutorial.el	2007-06-13 08:22:59.377470279 +0200
--- /home/wilde/src/emacs-hg-work/lisp/tutorial.el	2007-07-22 16:45:04.220919438 +0200
***************
*** 621,626 ****
--- 621,641 ----
  					      face tutorial-warning-face
  					      read-only t)))))))))))
  
+ (defun tutorial-get-language ()
+   "Use LC_ALL, LC_MESSAGES, LANG in turn to determine language to use.
+ This is more reliable then current-language-environment, which is not
+ intended to chose the language used for messages and documentation."
+   (let (locale (vars '("LC_ALL" "LC_MESSAGES" "LANG")))
+     (while (and vars
+ 		(= 0 (length locale))) ; nil or empty string
+       (setq locale (getenv (pop vars))))
+     (if (< 0 (length locale))
+ 	(let ((language (locale-name-match locale
+ 					   locale-language-names)))
+ 	  (if (consp language)
+ 	      (car language)
+ 	    language)))))
+ 
  (defun tutorial--saved-dir ()
    "Directory to which tutorials are saved."
    (expand-file-name "tutorial" user-emacs-directory))
***************
*** 766,774 ****
                         (add-hook 'minibuffer-setup-hook
                                   'minibuffer-completion-help)
                         (read-language-name 'tutorial "Language: " "English"))
!                    (if (get-language-info current-language-environment 'tutorial)
!                        current-language-environment
!                      "English")))
             (filename (get-language-info lang 'tutorial))
             ;; Choose a buffer name including the language so that
             ;; several languages can be tested simultaneously:
--- 781,790 ----
                         (add-hook 'minibuffer-setup-hook
                                   'minibuffer-completion-help)
                         (read-language-name 'tutorial "Language: " "English"))
!                    (or (tutorial-get-language)
! 		       (if (get-language-info current-language-environment 'tutorial)
! 			   current-language-environment
! 			 "English"))))
             (filename (get-language-info lang 'tutorial))
             ;; Choose a buffer name including the language so that
             ;; several languages can be tested simultaneously:

Diff finished.  Sun Jul 22 16:48:36 2007

[-- Attachment #3: Type: text/plain, Size: 203 bytes --]


-- 
Sascha Wilde : The most exciting phrase to hear in science, the one
             : that heralds new discoveries, is not "Eureka!" (I found
             : it!) but "That's funny ..." -- Isaac Asimov

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Better language detection for tutorial (was: set-locale-environement: strange default detection)

[Andreas Schwab]

Sascha Wilde <wilde@sha-bang.de> writes:

> + (defun tutorial-get-language ()
> +   "Use LC_ALL, LC_MESSAGES, LANG in turn to determine language to use.
> + This is more reliable then current-language-environment, which is not
                          than `...'
> + intended to chose the language used for messages and documentation."
                choose

> +   (let (locale (vars '("LC_ALL" "LC_MESSAGES" "LANG")))
> +     (while (and vars
> + 		(= 0 (length locale))) ; nil or empty string
                 zerop or (= (length locale) 0)

> +       (setq locale (getenv (pop vars))))

pop is a macro in cl.

> +     (if (< 0 (length locale))
            (> (length locale) 0)

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Better language detection for tutorial

[David Kastrup]

Andreas Schwab <schwab@suse.de> writes:

> Sascha Wilde <wilde@sha-bang.de> writes:
>
>> + (defun tutorial-get-language ()
>> +   "Use LC_ALL, LC_MESSAGES, LANG in turn to determine language to use.
>> + This is more reliable then current-language-environment, which is not
>                           than `...'
>> + intended to chose the language used for messages and documentation."
>                 choose
>
>> +   (let (locale (vars '("LC_ALL" "LC_MESSAGES" "LANG")))
>> +     (while (and vars
>> + 		(= 0 (length locale))) ; nil or empty string
>                  zerop or (= (length locale) 0)
>
>> +       (setq locale (getenv (pop vars))))
>
> pop is a macro in cl.

pop is a Lisp macro in `subr.el'.
(pop LISTNAME)

Return the first element of LISTNAME's value, and remove it from the list.
LISTNAME must be a symbol whose value is a list.
If the value is nil, `pop' returns nil but does not actually
change the list.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Better language detection for tutorial

[Sascha Wilde]

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

Andreas Schwab <schwab@suse.de> wrote:
> Sascha Wilde <wilde@sha-bang.de> writes:
>
>> + (defun tutorial-get-language ()
>> +   "Use LC_ALL, LC_MESSAGES, LANG in turn to determine language to use.
>> + This is more reliable then current-language-environment, which is not
>                           than `...'
>> + intended to chose the language used for messages and documentation."
>                 choose

Thanks, I changed that...

>> +   (let (locale (vars '("LC_ALL" "LC_MESSAGES" "LANG")))
>> +     (while (and vars
>> + 		(= 0 (length locale))) ; nil or empty string
>                  zerop or (= (length locale) 0)

I copied this part of the code from `mule-cmds.el',
set-locale-environment.  I intentionally didn't change the code, 
but I agree that your version is better style, so I changed that,
too.

>> +       (setq locale (getenv (pop vars))))
>
> pop is a macro in cl.

See Davids mail on this.

>> +     (if (< 0 (length locale))
>             (> (length locale) 0)

Originally written according to the code from `mule-cmds.el', changed.

New patch:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: emacs-tutorial-lang.patch --]
[-- Type: text/x-patch, Size: 2369 bytes --]

diff -c /usr/local/hg/emacs-hg/lisp/tutorial.el /home/wilde/src/emacs-hg-work/lisp/tutorial.el
*** /usr/local/hg/emacs-hg/lisp/tutorial.el	2007-06-13 08:22:59.377470279 +0200
--- /home/wilde/src/emacs-hg-work/lisp/tutorial.el	2007-07-22 22:14:52.079157597 +0200
***************
*** 621,626 ****
--- 621,641 ----
  					      face tutorial-warning-face
  					      read-only t)))))))))))
  
+ (defun tutorial-get-language ()
+   "Use LC_ALL, LC_MESSAGES, LANG in turn to determine language to use.
+ This is more reliable than current-language-environment, which is not
+ intended to choose the language used for messages and documentation."
+   (let (locale (vars '("LC_ALL" "LC_MESSAGES" "LANG")))
+     (while (and vars
+ 		(zerop (length locale))) ; nil or empty string
+       (setq locale (getenv (pop vars))))
+     (if (> (length locale) 0)
+ 	(let ((language (locale-name-match locale
+ 					   locale-language-names)))
+ 	  (if (consp language)
+ 	      (car language)
+ 	    language)))))
+ 
  (defun tutorial--saved-dir ()
    "Directory to which tutorials are saved."
    (expand-file-name "tutorial" user-emacs-directory))
***************
*** 766,774 ****
                         (add-hook 'minibuffer-setup-hook
                                   'minibuffer-completion-help)
                         (read-language-name 'tutorial "Language: " "English"))
!                    (if (get-language-info current-language-environment 'tutorial)
!                        current-language-environment
!                      "English")))
             (filename (get-language-info lang 'tutorial))
             ;; Choose a buffer name including the language so that
             ;; several languages can be tested simultaneously:
--- 781,790 ----
                         (add-hook 'minibuffer-setup-hook
                                   'minibuffer-completion-help)
                         (read-language-name 'tutorial "Language: " "English"))
!                    (or (tutorial-get-language)
! 		       (if (get-language-info current-language-environment 'tutorial)
! 			   current-language-environment
! 			 "English"))))
             (filename (get-language-info lang 'tutorial))
             ;; Choose a buffer name including the language so that
             ;; several languages can be tested simultaneously:

Diff finished.  Sun Jul 22 22:16:56 2007

[-- Attachment #3: Type: text/plain, Size: 143 bytes --]


-- 
Sascha Wilde   -.-. ..- .-. .. --- ... .. - -.-- 
               -.- .. .-.. .-.. . -.. 
               - .... .
               -.-. .- -

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Better language detection for tutorial

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> Andreas Schwab <schwab@suse.de> writes:
>
>> pop is a macro in cl.
>
> pop is a Lisp macro in `subr.el'.

Actually both. :-)

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Better language detection for tutorial

[Eli Zaretskii]

> From: Sascha Wilde <wilde@sha-bang.de>
> Date: Sun, 22 Jul 2007 22:20:18 +0200
> Cc: Thomas Arendsen Hein <thomas@intevation.de>, emacs-devel@gnu.org
> 
> !                    (or (tutorial-get-language)
> ! 		       (if (get-language-info current-language-environment 'tutorial)
> ! 			   current-language-environment
> ! 			 "English"))))

I think this is in wrong order: the `tutorial' property of the
language environment should have higher priority than what the new
function `tutorial-get-language' returns.

Re: Better language detection for tutorial

[Sascha Wilde]

Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Sascha Wilde <wilde@sha-bang.de>
>> 
>> !                    (or (tutorial-get-language)
>> ! 		       (if (get-language-info current-language-environment 'tutorial)
>> ! 			   current-language-environment
>> ! 			 "English"))))
>
> I think this is in wrong order: the `tutorial' property of the
> language environment should have higher priority than what the new
> function `tutorial-get-language' returns.

I highly doubt that, for all my tests (more complex locale setups,
that is) the tutorial property of the language environment yields
an unexpected (IMO wrong) language.

I haven't checked where and how it is set, but it seems to
ignore/misinterpret the LC environment, too.

Anyway maybe the language detection as I wrote it should be moved to
wherever the tutorial property is set...

cheers
sascha
-- 
Sascha Wilde
Well, *my* brain likes to think it's vastly more powerful than any
finite Turing machine but it hasn't proven that to me...
  -- Christopher Koppler in comp.lang.lisp

Re: Better language detection for tutorial

[Eli Zaretskii]

> Cc: thomas@intevation.de, schwab@suse.de, emacs-devel@gnu.org
> From: Sascha Wilde <wilde@sha-bang.de>
> Date: Mon, 23 Jul 2007 11:25:56 +0200
> 
> Eli Zaretskii <eliz@gnu.org> wrote:
> >> From: Sascha Wilde <wilde@sha-bang.de>
> >> 
> >> !                    (or (tutorial-get-language)
> >> ! 		       (if (get-language-info current-language-environment 'tutorial)
> >> ! 			   current-language-environment
> >> ! 			 "English"))))
> >
> > I think this is in wrong order: the `tutorial' property of the
> > language environment should have higher priority than what the new
> > function `tutorial-get-language' returns.
> 
> I highly doubt that, for all my tests (more complex locale setups,
> that is) the tutorial property of the language environment yields
> an unexpected (IMO wrong) language.

Please tell the details, then.  It's hard to argue with unspecified
results of unnamed tests.  Perhaps some of the values of the tutorial
property are simply wrong and need to be fixed.

In general, the tutorial property of the language environment should
be more accurate, since it is specific to Emacs, and specific to the
situation (i.e., reading the tutorial).  By contrast, the locale
environment variables are general and not limited to Emacs, so they
might be wrong for Emacs where general needs conflict with Emacs
tutorial needs.

> I haven't checked where and how it is set, but it seems to
> ignore/misinterpret the LC environment, too.

If by ``it'' you mean the tutorial property, then it does not depend
on any environment variables, it is set explicitly in the language
data base used by Emacs.  Here's an example:

    (set-language-info-alist
     "Brazilian Portuguese" '((tutorial . "TUTORIAL.pt_BR")
		(charset ascii latin-iso8859-1)
		(coding-system iso-latin-1 iso-latin-9)
		(coding-priority iso-latin-1)
		(nonascii-translation . latin-iso8859-1)
		(unibyte-syntax . "latin-1")
		(unibyte-display . iso-latin-1)
		(input-method . "latin-1-prefix")
		(sample-text . "Oi")
		(documentation . "Support for Brazilian Portuguese."))
     '("European"))

See lisp/language/*.el for more examples.

Re: Better language detection for tutorial

[Sascha Wilde]

Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Sascha Wilde <wilde@sha-bang.de>
>> Eli Zaretskii <eliz@gnu.org> wrote:
>> >> From: Sascha Wilde <wilde@sha-bang.de>
>> >> 
>> >> !                    (or (tutorial-get-language)
>> >> ! 		       (if (get-language-info current-language-environment 'tutorial)
>> >> ! 			   current-language-environment
>> >> ! 			 "English"))))
>> >
>> > I think this is in wrong order: the `tutorial' property of the
>> > language environment should have higher priority than what the new
>> > function `tutorial-get-language' returns.
>> 
>> I highly doubt that, for all my tests (more complex locale setups,
>> that is) the tutorial property of the language environment yields
>> an unexpected (IMO wrong) language.
>
> Please tell the details, then.  It's hard to argue with unspecified
> results of unnamed tests.

Please read my initial mail <m2k5sy2f3o.fsf@kenny.sha-bang.de> for a
complete, real world example.

[...]
> In general, the tutorial property of the language environment should
> be more accurate, since it is specific to Emacs, and specific to the
> situation (i.e., reading the tutorial).  By contrast, the locale
> environment variables are general and not limited to Emacs, so they
> might be wrong for Emacs where general needs conflict with Emacs
> tutorial needs.

The opposite is true: the LC_* environment variables provide a
universal way to define what i18n variant (language, data formatting
etc.) the user wants for specific aspects of applications.

A well behaved application should respect these settings.  But
currently Emacs potentially displays the tutorial in an language
unrelated to LC_MESSAGES, which is not what a user familiar with
locale settings would expect.

>> I haven't checked where and how it is set, but it seems to
>> ignore/misinterpret the LC environment, too.
>
> If by ``it'' you mean the tutorial property,

I do...

> then it does not depend on any environment variables,

which is an bug IMO, unless the user has chosen to set the tutorial
language explicit in Emacs.

> it is set explicitly in the language data base used by Emacs.
[...]

So the tutorial language is set based on the
current-language-environment, which is in turn determined (if not set
explicitly) in a way, disregarding the users choice for ui messages
language.  This is no good.

Making the tutorial property higher priority than my
`tutorial-get-language' would make my patch nearly useless...

cheers
sascha
-- 
Sascha Wilde

A conclusion is simply the place where someone got tired of thinking.

Re: Better language detection for tutorial

[David Kastrup]

Sascha Wilde <wilde@sha-bang.de> writes:

> Making the tutorial property higher priority than my
> `tutorial-get-language' would make my patch nearly useless...

"nearly"?  Is there actually a case where your patch would still do
anything?

But anyhow, the gist of this patch should be moved into the language
environment detection: there is no point in parading a tutorial
language that is not going to be actually used.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Better language detection for tutorial

[Eli Zaretskii]

> Cc: thomas@intevation.de, schwab@suse.de, emacs-devel@gnu.org
> From: Sascha Wilde <wilde@sha-bang.de>
> Date: Mon, 23 Jul 2007 22:29:16 +0200
> 
> >> > I think this is in wrong order: the `tutorial' property of the
> >> > language environment should have higher priority than what the new
> >> > function `tutorial-get-language' returns.
> >> 
> >> I highly doubt that, for all my tests (more complex locale setups,
> >> that is) the tutorial property of the language environment yields
> >> an unexpected (IMO wrong) language.
> >
> > Please tell the details, then.  It's hard to argue with unspecified
> > results of unnamed tests.
> 
> Please read my initial mail <m2k5sy2f3o.fsf@kenny.sha-bang.de> for a
> complete, real world example.

That's the message that started this discussion, right?  If so, it
just shows, AFAICT, that the way language environment is determined
might need fine-tuning.

Anyway, what you said (see above) seemed to indicate (``for all my
tests'', with ``tests'' in plural) that you have more than just a
single example, thus my request.  Apologies if I misunderstood you.

> > In general, the tutorial property of the language environment should
> > be more accurate, since it is specific to Emacs, and specific to the
> > situation (i.e., reading the tutorial).  By contrast, the locale
> > environment variables are general and not limited to Emacs, so they
> > might be wrong for Emacs where general needs conflict with Emacs
> > tutorial needs.
> 
> The opposite is true: the LC_* environment variables provide a
> universal way to define what i18n variant (language, data formatting
> etc.) the user wants for specific aspects of applications.

I'm obviously failing to explain myself: my point was _exactly_ that
universal settings might be applicable to Emacs needs not as well as
Emacs-specific defaults.  For example:

> A well behaved application should respect these settings.  But
> currently Emacs potentially displays the tutorial in an language
> unrelated to LC_MESSAGES, which is not what a user familiar with
> locale settings would expect.

It is not clear (at least to me, but it sounds like I'm not the only
one) that LC_MESSAGES is relevant to selecting the tutorial.  On a
GNU/Linux system, the locale(1) man page says:

	LC_MESSAGES
              Formats  of  informative and diagnostic messages and
              interactive responses.

and locale(7) says:

	LC_MESSAGES
              changes the language messages are displayed in and how
              an affirmative  or  negative  answer looks like. 

In other words, LC_MESSAGES talks about messages of the type Emacs
shows in the echo area.  It is not at all clear that the same setting
is good for the tutorial.

> So the tutorial language is set based on the
> current-language-environment, which is in turn determined (if not set
> explicitly) in a way, disregarding the users choice for ui messages
> language.  This is no good.

Then perhaps we should modify the way the language environment is
determined, and leave the tutorial alone.

In any case, please keep in mind that the language environment can be
set from ~/.emacs or interactively, not only from environment
variables.  I hope you are not saying that LC_MESSAGES should override
that as well.

> Making the tutorial property higher priority than my
> `tutorial-get-language' would make my patch nearly useless...

It sounds like fixing the way the language environment is determined
is a better way to solve this problem.  My interpretation of your
original report is that in that particular case, Emacs wrongly decided
that the user's language environment is German.  I hope you agree
that, if the language environment is indeed German, the user should be
shown a German tutorial.

Re: Better language detection for tutorial

[Kenichi Handa]

In article <E1IDDin-0007kU-EC@fencepost.gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> It sounds like fixing the way the language environment is determined
> is a better way to solve this problem.

Unfortunately, Emacs doesn't have such a language
environment which uses English as messages but uses German
settings for coding-system, input methods, etc.

Long ago, I proposed to generate a language environment
automatically from users locale settings (if none of
existring ones exactly match), but it was rejected (I don't
remember the detailed discussion).

I think his patch is an effective workaround for the current
problem.

By the way, which locale category to use for deciding the
default input method?

---
Kenichi Handa
handa@m17n.org

Re: Better language detection for tutorial

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> CC: wilde@sha-bang.de, thomas@intevation.de, schwab@suse.de,
>         emacs-devel@gnu.org
> Date: Tue, 24 Jul 2007 16:17:59 +0900
> 
> I think his patch is an effective workaround for the current
> problem.

But the patch would preclude users from changing the language
environment during an Emacs session, and having a corresponding
tutorial displayed as the result.  This sounds like a misfeature to
me.

> By the way, which locale category to use for deciding the
> default input method?

I don't know; is such information available via some system API?  If
not, our method of specifying the default in the language info is a
good solution.

Re: Better language detection for tutorial

[Kenichi Handa]

In article <E1IDEwD-0006kM-Vq@fencepost.gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> But the patch would preclude users from changing the language
> environment during an Emacs session, and having a corresponding
> tutorial displayed as the result.  This sounds like a misfeature to
> me.

Yes, but that situation is better than the current one
(i.e. showing incorrect tutorial from the first).  That's
why I wrote "workaround", not "fix".

And, anyway, one can do C-u C-h t to read the tutorial in
any (available) languages.

---
Kenichi Handa
handa@m17n.org

Re: Better language detection for tutorial

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> CC: wilde@sha-bang.de, thomas@intevation.de, emacs-devel@gnu.org
> Date: Tue, 24 Jul 2007 16:53:24 +0900
> 
> In article <E1IDEwD-0006kM-Vq@fencepost.gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:
> 
> > But the patch would preclude users from changing the language
> > environment during an Emacs session, and having a corresponding
> > tutorial displayed as the result.  This sounds like a misfeature to
> > me.
> 
> Yes, but that situation is better than the current one
> (i.e. showing incorrect tutorial from the first).  That's
> why I wrote "workaround", not "fix".

I still think a better workaround/fix would be to tweak the code that
determines the language environment from locale-related environment
variables, and then use the tutorial specified by that language
environment.

Re: Better language detection for tutorial

[Kenichi Handa]

In article <uvec9myik.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> I still think a better workaround/fix would be to tweak the code that
> determines the language environment from locale-related environment
> variables, and then use the tutorial specified by that language
> environment.

What exactly are you suggesting by "tweak the code"?
Generating a suitable language environment on demand (the
rejected proposal)?  If so, I fully agree.

---
Kenichi Handa
handa@m17n.org

Re: Better language detection for tutorial

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> CC: wilde@sha-bang.de, thomas@intevation.de, emacs-devel@gnu.org
> Date: Wed, 25 Jul 2007 10:01:55 +0900
> 
> In article <uvec9myik.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I still think a better workaround/fix would be to tweak the code that
> > determines the language environment from locale-related environment
> > variables, and then use the tutorial specified by that language
> > environment.
> 
> What exactly are you suggesting by "tweak the code"?

Examining the environment variables in different order and with
different logic, to determine the language environment.

Re: Better language detection for tutorial

[Kenichi Handa]

In article <usl7dmaxm.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> Examining the environment variables in different order and with
> different logic, to determine the language environment.

Impossible.  Emacs doesn't have a language environment that
matches with his request.

---
Kenichi Handa
handa@m17n.org

Re: Better language detection for tutorial

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> CC: wilde@sha-bang.de, thomas@intevation.de, emacs-devel@gnu.org
> Date: Wed, 25 Jul 2007 13:48:14 +0900
> 
> In article <usl7dmaxm.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Examining the environment variables in different order and with
> > different logic, to determine the language environment.
> 
> Impossible.  Emacs doesn't have a language environment that
> matches with his request.

Which is what?  I thought it was simply English.

Re: Better language detection for tutorial

[Kenichi Handa]

In article <ubqe0ffsb.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> > From: Kenichi Handa <handa@m17n.org>
> > CC: wilde@sha-bang.de, thomas@intevation.de, emacs-devel@gnu.org
> > Date: Wed, 25 Jul 2007 13:48:14 +0900
> > 
> > In article <usl7dmaxm.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:
> > 
> > > Examining the environment variables in different order and with
> > > different logic, to determine the language environment.
> > 
> > Impossible.  Emacs doesn't have a language environment that
> > matches with his request.

> Which is what?  I thought it was simply English.

No.  His locale settings are this:

LANG=en_US
LC_CTYPE=de_DE@euro
LC_MESSAGES="en_US"

So, coding-system must be latin-9 (iso-8859-15), but
messages (i.e. tutorial) must be English.

For this case, "Latin-9" language environment may be an
alternative one that will work, but it's just by chance (and
not easy to find it from the above setting).  For instance,
we don't have any alternative lang. env. for this:

LC_CTYPE=ja_JP
LC_MESSAGES="en_US"

---
Kenichi Handa
handa@m17n.org

Re: Better language detection for tutorial

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> CC: wilde@sha-bang.de, thomas@intevation.de, emacs-devel@gnu.org
> Date: Thu, 26 Jul 2007 11:29:48 +0900
> 
> LANG=en_US
> LC_CTYPE=de_DE@euro
> LC_MESSAGES="en_US"
> 
> So, coding-system must be latin-9 (iso-8859-15), but
> messages (i.e. tutorial) must be English.

How about if we set the language environment according to LANG and
LC_MESSAGES, and then set the preferred coding systems according to
LC_TYPE?  Will that do the trick?

> For this case, "Latin-9" language environment may be an
> alternative one that will work, but it's just by chance (and
> not easy to find it from the above setting).  For instance,
> we don't have any alternative lang. env. for this:
> 
> LC_CTYPE=ja_JP
> LC_MESSAGES="en_US"

Will my above suggestion work here as well?

Re: Better language detection for tutorial

[Kenichi Handa]

In article <E1IE1i6-0004D7-CT@fencepost.gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> How about if we set the language environment according to LANG and
> LC_MESSAGES, and then set the preferred coding systems according to
> LC_TYPE?  Will that do the trick?

That will be another workaround, but still has a problem.
Once one changes lang. env., he can never be back to the
original settings by set-language-environment.

---
Kenichi Handa
handa@m17n.org

Re: Better language detection for tutorial

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> CC: wilde@sha-bang.de, thomas@intevation.de, emacs-devel@gnu.org
> Date: Thu, 26 Jul 2007 21:19:12 +0900
> 
> > How about if we set the language environment according to LANG and
> > LC_MESSAGES, and then set the preferred coding systems according to
> > LC_TYPE?  Will that do the trick?
> 
> That will be another workaround, but still has a problem.
> Once one changes lang. env., he can never be back to the
> original settings by set-language-environment.

Not if we make the above suggestion part of set-language-environment
itself.

We could have optional behavior that instructed
set-language-environment whether to cater to LC_TYPE or not.
Interactively, it probably shouldn't by default do that, for example.

Re: Better language detection for tutorial

[Kenichi Handa]

In article <E1IE2PN-0004Pn-74@fencepost.gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> > That will be another workaround, but still has a problem.
> > Once one changes lang. env., he can never be back to the
> > original settings by set-language-environment.

> Not if we make the above suggestion part of set-language-environment
> itself.

> We could have optional behavior that instructed
> set-language-environment whether to cater to LC_TYPE or not.
> Interactively, it probably shouldn't by default do that, for example.

Then, Sascha's patch is the same.  We can make
help-with-tutorial cater to LC_MESSAGES or not.

---
Kenichi Handa
handa@m17n.org