Re: National Language Support Functions

Re: National Language Support Functions

[Eli Zaretskii]

> Date: Fri, 22 Dec 2006 01:11:01 +0100
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> CC:  jasonr@gnu.org

Could people who have access to MS-Windows please try these two
programs and report the results?  It is important to describe the full
details about your regional and international settings (found in
Control Panel) on each machine where you test this.

Thanks in advance.

> Eli Zaretskii wrote:
> > On my system, it returns Hebrew as the system default, and US English
> > as the user default, which is exactly how I configured this system.
> > So Emacs does the right thing for me.
> >
> > #include <windows.h>
> > #include <stdio.h>
> >
> > int main (void)
> > {
> >   LANGID lsys = GetSystemDefaultLangID ();
> >   LANGID lusr = GetUserDefaultLangID ();
> >
> >   printf ("SYS: 0x%x, USR: 0x%x\n", lsys, lusr);
> >
> >   return 0;
> > }
> >   
> 
> I think the tests above are not the correct tests for the UI language.
> 
> I searched a bit to find out again how to test this. It turns out to be 
> a bit complicated if one wants to support different versions of Windows. 
> I suggest that we only support later versions and then use 
> GetUserDefaultUILanguage and dito System variant. Here is some code to test:
> 
> #include <windows.h>
> #include <winnls.h>
> #include <windef.h>
> #include <tchar.h>
> #include <stdio.h>
> 
> #define TRACE(s, l)    (fprintf(stdout, s, l))
> 
> int main (void)
> {
>   LANGID lsys = GetSystemDefaultLangID ();
>   LANGID lusr = GetUserDefaultLangID ();
> 
>   printf ("LangID = SYS: 0x%x, USR: 0x%x\n", lsys, lusr);
> 
>   LCID lcidsys = GetSystemDefaultLCID ();
>   LCID lcidusr = GetUserDefaultLCID ();
> 
>   printf ("LCID = SYS: 0x%x, USR: 0x%x\n", lcidsys, lcidusr);
> 
>   //WINBASEAPI LANGID WINAPI GetSystemDefaultUILanguage(void);
>   //WINBASEAPI LANGID WINAPI GetUserDefaultUILanguage(void);
>   //LANGID luisys = GetSystemDefaultUILanguage();
>   //LANGID luiusr = GetUserDefaultUILanguage ();
> 
>   //printf ("UILang = SYS: 0x%x, USR: 0x%x\n", luisys, luiusr);
> 
>   {
>     LANGID langid = 0;
>     int nPrimaryLang = 0;
>     int nSubLang = 0;
>     LCID lcid = 0;
>     typedef LANGID (WINAPI * PFNGETUSERDEFAULTUILANGUAGE)
>       (
>        void);
>     PFNGETUSERDEFAULTUILANGUAGE pfnGetUserDefaultUILanguage;
>     typedef LANGID (WINAPI * PFNGETSYSTEMDEFAULTUILANGUAGE)
>       (
>        void);
>     PFNGETSYSTEMDEFAULTUILANGUAGE pfnGetSystemDefaultUILanguage;
>     HINSTANCE hKernel32;
> 
>     hKernel32 = GetModuleHandle(_T("kernel32.dll"));
>     pfnGetUserDefaultUILanguage =
>       (PFNGETUSERDEFAULTUILANGUAGE)GetProcAddress(hKernel32,"GetUserDefaultUILanguage");
>     if(pfnGetUserDefaultUILanguage != NULL)
>       {
>         langid = pfnGetUserDefaultUILanguage();
>         TRACE(_T("GetUserDefaultUILanguage() = %04X\n"), langid );
> 
>         pfnGetSystemDefaultUILanguage =
>           (PFNGETSYSTEMDEFAULTUILANGUAGE)GetProcAddress(hKernel32,"GetSystemDefaultUILanguage");
>         //ASSERT( pfnGetSystemDefaultUILanguage != NULL );
> 
>         langid = pfnGetSystemDefaultUILanguage();
>         TRACE(_T("GetSystemDefaultUILanguage = %04X\n"), langid );
>       }
>     else
>       {
>         // We're not on an MUI-capable system.
>         if (GetVersion()&0x80000000)
>           {
>             // We're on Windows 9x, so look
>             // in the registry for the UI language
>             HKEY hKey = NULL;
>             LONG nResult = RegOpenKeyEx(HKEY_CURRENT_USER,
>                                         _T( "Control Panel\\Desktop\\ResourceLocale" ),
>                                         0, KEY_READ, &hKey);
>             if (nResult == ERROR_SUCCESS)
>               {
>                 DWORD dwType;
>                 TCHAR szValue[16];
>                 ULONG nBytes = sizeof( szValue );
>                 nResult = RegQueryValueEx(hKey, NULL, NULL, &dwType,
>                                           (LPBYTE) szValue, &nBytes );
>                 if ((nResult == ERROR_SUCCESS) && (dwType == REG_SZ))
>                   {
>                     DWORD dwLangID;
>                     int nFields = _stscanf( szValue, _T( "%x" ), &dwLangID );
>                     if( nFields == 1 )
>                       {
>                         langid = (LANGID) dwLangID;
>                         TRACE(_T("Win 9x registry language = %04X\n"), langid );
>                       }
>                   }
>                 RegCloseKey(hKey);
>               }
>           }
>         else
>           {
>             // We're on NT 4. The UI language
>             // is the same as the language of the
>             // version resource in ntdll.dll
> /*             HMODULE hNTDLL = GetModuleHandle( _T( "ntdll.dll" ) ); */
> /*             if (hNTDLL != NULL) */
> /*               { */
> /*                 langid = 0; */
> /*                 EnumResourceLanguages( hNTDLL, RT_VERSION, MAKEINTRESOURCE( 1 ), */
> /*                                        _AfxEnumResLangProc, */
> /*                                        reinterpret_cast< LONG_PTR >( &langid ) ); */
> /*                 if (langid != 0) */
> /*                   { */
> /*                     AddLangId( langid ); */
> /*                     TRACE(_T("CMultiLanguage::DetectUILanguage() NT1st/2nd = %04X\n"), langid ); */
> /*                   } */
> /*               } */
>           }
>       }
> 
> 
>   }
>   return 0;
> }
> 
> 

Re: National Language Support Functions

[Jason Rumney]

Eli Zaretskii wrote:
>> Date: Fri, 22 Dec 2006 01:11:01 +0100
>> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
>> CC:  jasonr@gnu.org
>>     
>
> Could people who have access to MS-Windows please try these two
> programs and report the results?  It is important to describe the full
> details about your regional and international settings (found in
> Control Panel) on each machine where you test this.
>
> Thanks in advance.
>   
This is on the UK English version of Windows XP

LangID = SYS: 0x809, USR: 0x809        [en_GB]
LCID = SYS: 0x809, USR: 0x809          [en_GB]
GetUserDefaultUILanguage() = 0409      [en]
GetSystemDefaultUILanguage = 0409     [en]

Regional Options:

Standards and formats: English (United Kingdom)
Location: United Kingdom

Advanced:
Language for non-Unicode programs: English (United Kingdom)



As far as I can tell from documentation, GetSystemDefaultUILanguage() 
and GetUserDefaultUILanguage() return a constant value that the user has 
no control over on all versions of Windows ME and XP Home, and most 
versions of Windows 2000, XP Professional and Server 2003. The exception 
to this is certain large corporate customers who get a special version 
of Windows so they can deploy a single OS image across all their 
machines regardless of language. For those cases, 
GetSystemDefaultUILanguage() should always return 0409 (english), as 
these images are based on the English version of Windows. 
GetUserDefaultUILanguage() result can be changed by the user at login, 
or by the administrators in policy files.

Since the first set of values can be changed by the user on all versions 
of windows, I think it is more appropriate to use these in Emacs. They 
also seem to be more precise, offering the sub-language as well as the 
main language.

The fact that these can get out of step, as Lennart has managed to do on 
his machine, seems to be a bug in Windows, and I think it is an edge 
case we shouldn't worry about. Some of Lennart's settings state that 
Swedish should be used on his computer, so he should not be surprised 
when programs such as Emacs take notice of that.

Re: National Language Support Functions

[Jason Rumney]

Jason Rumney wrote:
> This is on the UK English version of Windows XP
>
> LangID = SYS: 0x809, USR: 0x809        [en_GB]
> LCID = SYS: 0x809, USR: 0x809          [en_GB]
> GetUserDefaultUILanguage() = 0409      [en]
> GetSystemDefaultUILanguage = 0409     [en]
Actually, the [en], which came from 
http://www.microsoft.com/globaldev/reference/win2k/setup/Langid.mspx is 
incorrect.

These values are actually [en_US]. Nothing in my OS settings specifies 
US English. So these values are just plain wrong.

It appears that these last two API functions report the localization 
package used by the Windows UI itself, which is distinct from the user's 
preferences for language settings they make in the control panel.

Re: National Language Support Functions

[Eli Zaretskii]

> Date: Fri, 22 Dec 2006 12:57:02 +0000
> From: Jason Rumney <jasonr@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-pretest-bug@gnu.org,
> 	emacs-devel@gnu.org
> >
> > LangID = SYS: 0x809, USR: 0x809        [en_GB]
> > LCID = SYS: 0x809, USR: 0x809          [en_GB]
> > GetUserDefaultUILanguage() = 0409      [en]
> > GetSystemDefaultUILanguage = 0409     [en]
> Actually, the [en], which came from 
> http://www.microsoft.com/globaldev/reference/win2k/setup/Langid.mspx is 
> incorrect.
> 
> These values are actually [en_US]. Nothing in my OS settings specifies 
> US English. So these values are just plain wrong.
> 
> It appears that these last two API functions report the localization 
> package used by the Windows UI itself, which is distinct from the user's 
> preferences for language settings they make in the control panel.

Yep, looks like that.  I guess those values are set when you answer
the question you are asked during Windows installation: whether you
want the Windows menus and dialogs in English or in your locale's
language.  If I'm right, these values can be changed only by
re-installing Windows.

Re: National Language Support Functions

[Lennart Borgman]

Eli Zaretskii wrote:
>> Date: Fri, 22 Dec 2006 12:57:02 +0000
>> From: Jason Rumney <jasonr@gnu.org>
>> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-pretest-bug@gnu.org,
>> 	emacs-devel@gnu.org
>>     
>>> LangID = SYS: 0x809, USR: 0x809        [en_GB]
>>> LCID = SYS: 0x809, USR: 0x809          [en_GB]
>>> GetUserDefaultUILanguage() = 0409      [en]
>>> GetSystemDefaultUILanguage = 0409     [en]
>>>       
>> Actually, the [en], which came from 
>> http://www.microsoft.com/globaldev/reference/win2k/setup/Langid.mspx is 
>> incorrect.
>>
>> These values are actually [en_US]. Nothing in my OS settings specifies 
>> US English. So these values are just plain wrong.
>>
>> It appears that these last two API functions report the localization 
>> package used by the Windows UI itself, which is distinct from the user's 
>> preferences for language settings they make in the control panel.
>>     
>
> Yep, looks like that.  I guess those values are set when you answer
> the question you are asked during Windows installation: whether you
> want the Windows menus and dialogs in English or in your locale's
> language.  If I'm right, these values can be changed only by
> re-installing Windows.
>   
Re-installing Windows or using their Multilingual package.

On my XP pc I found I can change LanID and LCID for USR above. I do that 
in the

    Control Panel
        Regional and Language Options
            Region Options tab
                Standards and formats

Everything there is about things like date, currence etc. There is 
nothing about spoken/written language there.

If we where to use the language for menus etc in Emacs I guess everyone 
would agree that we would use GetUserDefaultUILanguage, or? Is there any 
reason we should not do the same for the tutorial?

Re: National Language Support Functions

[Benjamin Riefenstahl]

Hi Eli,


Eli Zaretskii writes:
> Could people who have access to MS-Windows please try these two
> programs and report the results?

On W2K, US-English version, but with the general locale, keyboard
layout and other settings set to German:

  I:\Projects\test-nls> .\test1
  SYS: 0x407, USR: 0x407

  I:\Projects\test-nls> .\test2
  LangID = SYS: 0x407, USR: 0x407
  LCID = SYS: 0x407, USR: 0x407
  GetUserDefaultUILanguage() = 0409
  GetSystemDefaultUILanguage = 0409

On W98, German version, no changes to the German defaults:

  C:\benny>test1
  SYS: 0x407, USR: 0x407

  C:\benny>test2
  LangID = SYS: 0x407, USR: 0x407
  LCID = SYS: 0x407, USR: 0x407
  Win 9x registry language = 0407


benny

Re: National Language Support Functions

[Eli Zaretskii]

> Cc: emacs-pretest-bug@gnu.org, emacs-devel@gnu.org,
>    Lennart Borgman <lennart.borgman.073@student.lu.se>
> From: Benjamin Riefenstahl <b.riefenstahl@turtle-trading.net>
> Date: Fri, 22 Dec 2006 17:32:58 +0100
> 
> On W2K, US-English version, but with the general locale, keyboard
> layout and other settings set to German:
> 
>   I:\Projects\test-nls> .\test1
>   SYS: 0x407, USR: 0x407
> 
>   I:\Projects\test-nls> .\test2
>   LangID = SYS: 0x407, USR: 0x407
>   LCID = SYS: 0x407, USR: 0x407
>   GetUserDefaultUILanguage() = 0409
>   GetSystemDefaultUILanguage = 0409
> 
> On W98, German version, no changes to the German defaults:
> 
>   C:\benny>test1
>   SYS: 0x407, USR: 0x407
> 
>   C:\benny>test2
>   LangID = SYS: 0x407, USR: 0x407
>   LCID = SYS: 0x407, USR: 0x407
>   Win 9x registry language = 0407

And what tutorial would you expect Emacs to present to you? the German
one or the English one?

Re: National Language Support Functions

[Benjamin Riefenstahl]

Hi Eli,


Benjamin Riefenstahl writes:
>> On W2K, US-English version, but with the general locale, keyboard
>> layout and other settings set to German:
>> 
>>   I:\Projects\test-nls> .\test1
>>   SYS: 0x407, USR: 0x407
>> 
>>   I:\Projects\test-nls> .\test2
>>   LangID = SYS: 0x407, USR: 0x407
>>   LCID = SYS: 0x407, USR: 0x407
>>   GetUserDefaultUILanguage() = 0409
>>   GetSystemDefaultUILanguage = 0409

Eli Zaretskii writes:
> And what tutorial would you expect Emacs to present to you? the
> German one or the English one?

The language of my UI, i.e. English.  I use English OS versions
because I prefer to learn and use the original terminology.


benny

Re: National Language Support Functions

[Kenichi Handa]

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

> Could people who have access to MS-Windows please try these two
> programs and report the results?  It is important to describe the full
> details about your regional and international settings (found in
> Control Panel) on each machine where you test this.

I couldn't compile the second program (saved as mstest.c) by
gcc in my Cygwin environment.  This is the error log.

[IBM-F5F27A11743:~:516] gcc mstest.c
mstest.c:4:19: tchar.h: No such file or directory
mstest.c: In function `main':
mstest.c:43: warning: passing arg 1 of `GetModuleHandleA' makes pointer from integer without a cast
mstest.c:49: warning: passing arg 2 of `fprintf' makes pointer from integer without a cast
mstest.c:56: warning: passing arg 2 of `fprintf' makes pointer from integer without a cast
mstest.c:68: warning: passing arg 2 of `RegOpenKeyExA' makes pointer from integer without a cast
mstest.c:83: warning: passing arg 2 of `fprintf' makes pointer from integer without a cast
[IBM-F5F27A11743:~:517] 

As I found tchar.h under /usr/include/mingw, I supplied
-I/usr/incldue/mingw to gcc, but got this error.

[IBM-F5F27A11743:~:516] gcc -I/usr/include/mingw mstest.c
/cygdrive/c/DOCUME~1/handa/LOCALS~1/Temp/ccmE5qPc.o:mstest.c:(.text+0xeb): undefined reference to `__imp___iob'
/cygdrive/c/DOCUME~1/handa/LOCALS~1/Temp/ccmE5qPc.o:mstest.c:(.text+0x12d): undefined reference to `__imp___iob'
/cygdrive/c/DOCUME~1/handa/LOCALS~1/Temp/ccmE5qPc.o:mstest.c:(.text+0x214): undefined reference to `__imp___iob'
collect2: ld returned 1 exit status
[IBM-F5F27A11743:~:517]

I have no idea what to do.

---
Kenichi Handa
handa@m17n.org

Re: National Language Support Functions

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> CC: emacs-pretest-bug@gnu.org, emacs-devel@gnu.org
> Date: Mon, 25 Dec 2006 15:17:42 +0900
> 
> I couldn't compile the second program (saved as mstest.c) by
> gcc in my Cygwin environment.  This is the error log.
> 
> [IBM-F5F27A11743:~:516] gcc mstest.c
> mstest.c:4:19: tchar.h: No such file or directory
> mstest.c: In function `main':
> mstest.c:43: warning: passing arg 1 of `GetModuleHandleA' makes pointer from integer without a cast
> mstest.c:49: warning: passing arg 2 of `fprintf' makes pointer from integer without a cast
> mstest.c:56: warning: passing arg 2 of `fprintf' makes pointer from integer without a cast
> mstest.c:68: warning: passing arg 2 of `RegOpenKeyExA' makes pointer from integer without a cast
> mstest.c:83: warning: passing arg 2 of `fprintf' makes pointer from integer without a cast
> [IBM-F5F27A11743:~:517] 

Try passing the -mno-cygwin switch to GCC.

Re: National Language Support Functions

[Kenichi Handa]

In article <uzm9b1z4y.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:
> Try passing the -mno-cygwin switch to GCC.

Ah.  Thank you.   This is the result.

Program1:
SYS: 0x411, USR: 0x411

Program2:
LangID = SYS: 0x411, USR: 0x411
LCID = SYS: 0x411, USR: 0x411
GetUserDefaultUILanguage() = 0411
GetSystemDefaultUILanguage = 0411

This is Windows XP SP2, with the following Regional Settings
(translated from Japanase):

  . In the Regional Options tab:
    . In "Standard and formats": Japanese
    . In "Location": Japan
  . In the Languages tab:
    . Clicking on Details shows:
      . In the Settings tab:
      	. Default input language: Japanese - Microsoft Input 2003
      . In the Advanced tab:
      	. Every check box is unchecked
  . In the Advanced tab:
    . Language for non-Unicode programs: Japanese

But, when I change "Language for non-Unicode programs" to
Chinese (China), and reboot the system, the result of the
programs changed as this:

Program1:
SYS: 0x804, USR: 0x411

Program2:
LangID = SYS: 0x805, USR: 0x411
LCID = SYS: 0x411, USR: 0x411
GetUserDefaultUILanguage() = 0411
GetSystemDefaultUILanguage = 0411

---
Kenichi Handa
handa@m17n.org

Re: National Language Support Functions

[Jason Rumney]

Kenichi Handa wrote:
> I couldn't compile the second program (saved as mstest.c) by
> gcc in my Cygwin environment.  This is the error log.
>   
To compile a native Windows program with Cygwin gcc, you need to use 
-mno-cygwin.

Re: National Language Support Functions

[Lennart Borgman (gmail)]

We never made any decision on this issue. Most of the answers pointed to 
that GetUserDefaultUILanguage is the correct function to use. Or am I 
just misinterpreting to confirm what I said at the beginning ;-)

Re: National Language Support Functions

[Eli Zaretskii]

> Date: Thu, 28 Dec 2006 14:03:45 +0100
> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
> Cc: 
> 
> We never made any decision on this issue. Most of the answers pointed to 
> that GetUserDefaultUILanguage is the correct function to use. Or am I 
> just misinterpreting to confirm what I said at the beginning ;-)

My conclusion is different.  I think we do use the correct interface:

   GetLocaleInfo (LOCALE_USER_DEFAULT, LOCALE_SABBREVLANGNAME ...

This queries the OS about the user-selected _language_ in the current
locale, so it's supposed to be akin to the Posix LANG parameter.
However, Microsoft have their i18n API hopelessly messed up, in that
they have too many different language-related settings, their mapping
to the related APIs is confusing and under-documented, and the
associated guidelines change with every Windows version (the clear
sign of the latter is that each new Windows version introduces another
bunch of new functions that return the language).

At least one user of those who reported the results of your program
(Jason) would be hurt by going to GetUserDefaultUILanguage.  Also,
that API returns a language that cannot be easily changed, unlike the
language that we currently return (see above).

So my conclusion is that we should leave things as they are.  If it
annoys you that your system brings you the wrong tutorial, you can
either change the Windows language settings, or simply request the
tutorial in any language you like, with "C-u C-h t".

Re: National Language Support Functions

[Lennart Borgman (gmail)]

Eli Zaretskii wrote:
>> Date: Thu, 28 Dec 2006 14:03:45 +0100
>> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
>> Cc: 
>>
>> We never made any decision on this issue. Most of the answers pointed to 
>> that GetUserDefaultUILanguage is the correct function to use. Or am I 
>> just misinterpreting to confirm what I said at the beginning ;-)
>>     
>
> My conclusion is different.  I think we do use the correct interface:
>
>    GetLocaleInfo (LOCALE_USER_DEFAULT, LOCALE_SABBREVLANGNAME ...
>
> This queries the OS about the user-selected _language_ in the current
> locale, so it's supposed to be akin to the Posix LANG parameter.
> However, Microsoft have their i18n API hopelessly messed up, in that
> they have too many different language-related settings, their mapping
> to the related APIs is confusing and under-documented, and the
> associated guidelines change with every Windows version (the clear
> sign of the latter is that each new Windows version introduces another
> bunch of new functions that return the language).
>   

I think that MS just tries to adopt to different needs the users have. 
It is not productive to just dismiss the struggle MS have with this 
things. Maybe they are not doing things the best way, but that is a 
quite different matter. We should in my opinion try to do what the user 
wants. There are users who wants to read English but use another 
keyboard layout etc. For example Firefox and Thunderbird agrees on this, 
while GIMP does not. It looks to me that the users have had a much 
bigger impact in the case of Firefox and Thunderbird than when it comes 
to GIMP. Accessibility guidelines are for example followed in Firefox 
and Thunderbird but not in GIMP.

What does GNOME do in this area? Does it allow the user to use a Swedish 
keyboard layout but still have English as the preferred language for 
text to show?


> At least one user of those who reported the results of your program
> (Jason) would be hurt by going to GetUserDefaultUILanguage.  Also,
> that API returns a language that cannot be easily changed, unlike the
> language that we currently return (see above).
>   

Yes, I saw Jasons problem. Could we look a bit closer at this? I did not 
understand the details so far.

> So my conclusion is that we should leave things as they are.  If it
> annoys you that your system brings you the wrong tutorial, you can
> either change the Windows language settings, or simply request the
> tutorial in any language you like, with "C-u C-h t".
>
>   

Re: National Language Support Functions

[Jan Djärv]

Lennart Borgman (gmail) skrev:

> 
> What does GNOME do in this area? Does it allow the user to use a Swedish 
> keyboard layout but still have English as the preferred language for 
> text to show?
> 

Of course.  There is no connection between keyboard layout and language text.

	Jan D.

Re: National Language Support Functions

[Lennart Borgman (gmail)]

Jan Djärv wrote:
>
>
> Lennart Borgman (gmail) skrev:
>
>>
>> What does GNOME do in this area? Does it allow the user to use a 
>> Swedish keyboard layout but still have English as the preferred 
>> language for text to show?
>>
>
> Of course.  There is no connection between keyboard layout and 
> language text.

Thanks.

Re: National Language Support Functions

[Jason Rumney]

Lennart Borgman (gmail) wrote:
> We never made any decision on this issue. Most of the answers pointed 
> to that GetUserDefaultUILanguage is the correct function to use. Or am 
> I just misinterpreting to confirm what I said at the beginning ;-)

You are just misinterpreting to agree with what you yourself believe. 
Benjamin Riefenstahl had a similar setup as yourself, with a non-English 
locale on an English localized version of Windows, and he too would 
prefer the English tutorial, but I don't think we should limit ourselves 
to the languages that Windows has been translated to, and in some cases 
this is plainly the wrong language to use.

Re: National Language Support Functions

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> Lennart Borgman (gmail) wrote:
>> We never made any decision on this issue. Most of the answers pointed 
>> to that GetUserDefaultUILanguage is the correct function to use. Or 
>> am I just misinterpreting to confirm what I said at the beginning ;-)
>
> You are just misinterpreting to agree with what you yourself believe. 
> Benjamin Riefenstahl had a similar setup as yourself, with a 
> non-English locale on an English localized version of Windows, and he 
> too would prefer the English tutorial, but I don't think we should 
> limit ourselves to the languages that Windows has been translated to, 
> and in some cases this is plainly the wrong language to use.

I am sorry, but I do not at all understand what you mean. What do you 
mean with that "I don't think we should limit ourselves to the languages 
that Windows has been translated to"? Have we discussed that at all? Is 
not this discussion about how to choose the correct language for text to 
be shown inside Emacs (in this case the tutorial of couse)?

BTW I just noticed that GIMP makes the same decision about language and 
it is quite disastrous. Everything is in Swedish. However if I need to 
search the Internet for information about GIMP then most tips are in 
English. I have however no way of knowning the English names of things 
within GIMP any more. Except of course by changing the keyboard to 
English, but then I had big trouble searching the Internet ;-)

It would be very good if we continued this discussion. It may not matter 
very much for those using an English keyboard layout, but it 
definitively does if you use for example a Swedish keyboard layout.

Re: National Language Support Functions

[Jason Rumney]

Lennart Borgman (gmail) wrote:
> Jason Rumney wrote:
>> Lennart Borgman (gmail) wrote:
>>> We never made any decision on this issue. Most of the answers 
>>> pointed to that GetUserDefaultUILanguage is the correct function to 
>>> use. Or am I just misinterpreting to confirm what I said at the 
>>> beginning ;-)
>>
>> You are just misinterpreting to agree with what you yourself believe. 
>> Benjamin Riefenstahl had a similar setup as yourself, with a 
>> non-English locale on an English localized version of Windows, and he 
>> too would prefer the English tutorial, but I don't think we should 
>> limit ourselves to the languages that Windows has been translated to, 
>> and in some cases this is plainly the wrong language to use.
>
> I am sorry, but I do not at all understand what you mean. What do you 
> mean with that "I don't think we should limit ourselves to the 
> languages that Windows has been translated to"? Have we discussed that 
> at all? Is not this discussion about how to choose the correct 
> language for text to be shown inside Emacs (in this case the tutorial 
> of couse)?

The function you are suggesting we use returns the language used by 
Windows itself for its UI. If we use that function to determine the 
user's language preference, we (1) limit the language selection to 
languages that Windows has been localized in, and (2) the language 
cannot be changed by the user after installation except in Vista and 
installations of Windows 2000/XP that Microsoft makes available only to 
large multinational corporations.

> It would be very good if we continued this discussion. It may not 
> matter very much for those using an English keyboard layout, but it 
> definitively does if you use for example a Swedish keyboard layout.
I don't see why keyboard layout has anything to do with it. The language 
that Emacs (and Gimp) uses is determined by the user's locale settings, 
not by the keyboard layout.

Re: National Language Support Functions

[Lennart Borgman (gmail)]

Jason Rumney wrote:
>> I am sorry, but I do not at all understand what you mean. What do you 
>> mean with that "I don't think we should limit ourselves to the 
>> languages that Windows has been translated to"? Have we discussed 
>> that at all? Is not this discussion about how to choose the correct 
>> language for text to be shown inside Emacs (in this case the tutorial 
>> of couse)?
>
> The function you are suggesting we use returns the language used by 
> Windows itself for its UI. If we use that function to determine the 
> user's language preference, we (1) limit the language selection to 
> languages that Windows has been localized in, and (2) the language 
> cannot be changed by the user after installation except in Vista and 
> installations of Windows 2000/XP that Microsoft makes available only 
> to large multinational corporations.
>
>> It would be very good if we continued this discussion. It may not 
>> matter very much for those using an English keyboard layout, but it 
>> definitively does if you use for example a Swedish keyboard layout.
> I don't see why keyboard layout has anything to do with it. The 
> language that Emacs (and Gimp) uses is determined by the user's locale 
> settings, not by the keyboard layout.


Thanks, you got me there. You are right. I was somehow unconscious 
assuming that the keyboard layout and the language we choosed where 
related, but they are not of course.

So I am convinced. It is better to leave it as it is now. And GIMP is 
correct to regarding the language choice.

Re: National Language Support Functions

[Juanma Barranquero]

On 12/29/06, Lennart Borgman (gmail) <lennart.borgman@gmail.com> wrote:

> It would be very good if we continued this discussion.

And if no agreement can be reached, will you add another patch to your
binary Emacs distribution and make it still more divergent, or will
you accept that perhaps it is better to leave it as it stands now?

                    /L/e/k/t/u

Re: National Language Support Functions

[Lennart Borgman]

Juanma Barranquero wrote:
> On 12/29/06, Lennart Borgman (gmail) <lennart.borgman@gmail.com> wrote:
> 
>> It would be very good if we continued this discussion.
> 
> And if no agreement can be reached, will you add another patch to your
> binary Emacs distribution and make it still more divergent, or will
> you accept that perhaps it is better to leave it as it stands now?


I have already said I agreed. Somehow I misunderstood the problem 
thinking that keyboard layout was involved. It is not and I really do 
not understand why I thought that.

Sorry for the trouble, but at least I know now how Emacs works in this 
area and why the choice was made. It would probably be good if it was 
explained in the manual.

I have no intention of making my Emacs binary distribution be different 
from Emacs default if I can avoid it. On the other hand there are still 
bugs I know about that affects the w32 side mostly. I will tell as soon 
as I get time. I have made no patches for those bugs and would be glad 
if we fixed them instead.

The purpose of my binary distribution was (as I several times has said) 
to make it more easy to get Emacs up and running on w32. I was surprised 
that it was so difficult and time consuming. I know it is not a very 
high priority to make this easier, mostly because of lack of resources.

Re: National Language Support Functions

[Juanma Barranquero]

On 12/29/06, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:

> I have already said I agreed.

Yes. My mind was wandering around, lost in the concept of awfulness,
and I got carried away. Sorry.

> I have no intention of making my Emacs binary distribution be different
> from Emacs default if I can avoid it.

Of course. But your threshold for deciding that it cannot be avoided
doesn't seem hard to reach.

> The purpose of my binary distribution was (as I several times has said)
> to make it more easy to get Emacs up and running on w32. I was surprised
> that it was so difficult and time consuming.

Compiling Emacs on Windows can be time-consuming. Setting it up is not IMHO.

                    /L/e/k/t/u

Re: National Language Support Functions

[Lennart Borgman (gmail)]

Juanma Barranquero wrote:
> On 12/29/06, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:
>
>> I have already said I agreed.
>
> Yes. My mind was wandering around, lost in the concept of awfulness,
> and I got carried away. Sorry.

No problem. I felt myself I did not listen carefully enough to what was 
said about the original problem. I try to do, but sometimes I lost my way.

>
>> I have no intention of making my Emacs binary distribution be different
>> from Emacs default if I can avoid it.
>
> Of course. But your threshold for deciding that it cannot be avoided
> doesn't seem hard to reach.

It is personal of course ;-)   - But on the other hand I have noticed 
that most users dowloading from my site prefer the patched version.

>
>> The purpose of my binary distribution was (as I several times has said)
>> to make it more easy to get Emacs up and running on w32. I was surprised
>> that it was so difficult and time consuming.
>
> Compiling Emacs on Windows can be time-consuming. Setting it up is not 
> IMHO.

Yes, getting starting compiling was a big problem, but now I have 
everything setup and it is very easy to compile and upload. I just type 
"doit". The unpatched version I do not test at all. The patched version 
I test before I move it to the download area on the web site.

You need to get the external tools and set them up to to get the most 
out of Emacs. Including a basic subset of them in a distribution is 
therefore useful in my opinion. Or having that as a separate distribution.

Re: National Language Support Functions

[Juanma Barranquero]

On 12/29/06, Lennart Borgman (gmail) <lennart.borgman@gmail.com> wrote:

> - But on the other hand I have noticed
> that most users dowloading from my site prefer the patched version.

That is not saying much, IMO. If you put package X on a site, and Y,
described as "X with all bells and whistles for Windows", is not hard
to see why people would download Y even before knowing whether X is
good enough for them.

> You need to get the external tools and set them up to to get the most
> out of Emacs. Including a basic subset of them in a distribution is
> therefore useful in my opinion. Or having that as a separate distribution.

Most users of Emacs are programmers; a pointer to the place to
download the tools would surely be enough. But that's not what I was
talking about. There's no need to patch Emacs for that.

                    /L/e/k/t/u

Re: National Language Support Functions

[Lennart Borgman (gmail)]

Juanma Barranquero wrote:
> On 12/29/06, Lennart Borgman (gmail) <lennart.borgman@gmail.com> wrote:
>
>> - But on the other hand I have noticed
>> that most users dowloading from my site prefer the patched version.
>
> That is not saying much, IMO. If you put package X on a site, and Y,
> described as "X with all bells and whistles for Windows", is not hard
> to see why people would download Y even before knowing whether X is
> good enough for them.

That is not really what I do with the patches. I try to describe in full 
enough details for everyone to decide for themselves:

    http://ourcomments.org/Emacs/EmacsW32.html#unpatched


> Most users of Emacs are programmers; a pointer to the place to
> download the tools would surely be enough. But that's not what I was
> talking about. There's no need to patch Emacs for that.

Actually I was looking for a good tool writing web pages too when I 
started using Emacs. I was so tired of all different tools with their 
different shortcomings, time to learn, time to install etc.

I had an idea: maybe Emacs could be made to a powerful enough tool for 
web pages so that non programmers can use it too? Installation, 
friendliness of the GUI etc. That is still what I am trying to do. On my 
way I stumble on a lot of things in Emacs. That is not very bad. That 
was what I wanted to test.

BTW, after the release I hope we can include nxml-mode. It is very 
powerful, well written -- and hard to understand code. I wonder if rng 
can be used further in Emacs. I do not know the limitations of such 
approaches, but with a language like XML it seems very good. I thought 
about using it for CSS but gave up. I did not understand the structure 
of the code or potential syntax problems well enough to fight it.

Re: National Language Support Functions

[Juanma Barranquero]

On 12/29/06, Lennart Borgman (gmail) <lennart.borgman@gmail.com> wrote:

> That is not really what I do with the patches.

It'd be unexpected for Windows users to choose your version after reading these:

  "It can make the keyboard and other things in Emacs function more
like they do usually in MS Windows programs."

  "The CVS Emacs binaries that comes with EmacsW32 are normally
changed a little bit to make them work better on MS Windows."

This one is my favourite:

  "Those changes should preferably be incorporated in Emacs, but
currently they can not be that. The main reason for this is that it is
to close to release of the next version of Emacs to have time to test
new features that could break Emacs."

I'd say, the main reason is that there has been lack of agreement on
whether they were really needed, and if so, that they were the best
fix for the problem. But most people will understand that it is only a
matter of time till these patches are in the CVS trunk.

> Actually I was looking for a good tool writing web pages too when I
> started using Emacs. I was so tired of all different tools with their
> different shortcomings, time to learn, time to install etc.

Yes, that's a good reason for you to customize your Emacs. That does
not mean that many people needs the same customizations and patches
(for example, the low-level keyboard hook).

                    /L/e/k/t/u

Re: National Language Support Functions

[Lennart Borgman (gmail)]

Juanma Barranquero wrote:
> On 12/29/06, Lennart Borgman (gmail) <lennart.borgman@gmail.com> wrote:
>
>> That is not really what I do with the patches.
>
> It'd be unexpected for Windows users to choose your version after 
> reading these:
>
>  "It can make the keyboard and other things in Emacs function more
> like they do usually in MS Windows programs."

Please explain a little bit more.

> This one is my favourite:
>
>  "Those changes should preferably be incorporated in Emacs, but
> currently they can not be that. The main reason for this is that it is
> to close to release of the next version of Emacs to have time to test
> new features that could break Emacs."
>
> I'd say, the main reason is that there has been lack of agreement on
> whether they were really needed, and if so, that they were the best
> fix for the problem. But most people will understand that it is only a
> matter of time till these patches are in the CVS trunk.

You mean that they read my text that way? Yes, maybe the main reason is 
lack of agreement that these patches are really needed. Then what do you 
expect me to do?

I do not care a second what way this changes are coded as long as they 
adhere to the MS Windows documentation. Though I am getting tired of 
saying things over and over again. What about that patch that tells 
Emacs to save the changes when a user logs off? I included that in my 
patched version nearly half a year ago since I did not want to loose my 
work. Is it included in Emacs today?


>
>> Actually I was looking for a good tool writing web pages too when I
>> started using Emacs. I was so tired of all different tools with their
>> different shortcomings, time to learn, time to install etc.
>
> Yes, that's a good reason for you to customize your Emacs. That does
> not mean that many people needs the same customizations and patches
> (for example, the low-level keyboard hook). 

Yes, I do not want to switch application just because I want to write 
some web pages instead of doing some kind of programmning. (If you can 
diviide those things today.)

The low level keyboard hook that allows Emacs to use the left and right 
windows keys as Emacs meta key should in my opinion be a very 
uncontroversial issue. That is simply the way to do it on MS Windows 
according to the documentation. Currently there is some workarounds in 
Emacs and they do not work in all cases which at least have been 
documented now, but it is hard for me to understand why it should be 
scary to use a low level keyboard hook. (In fact I do suspect from the 
feedback I have tot that it has to do with some misunderstanding of how 
a low level keyboard works in MS Windows now. Previously, if I do not 
misremember, you have to install it on a more global level than today. 
People where doing that for keyboard listeners etc.)

Re: National Language Support Functions

[Juanma Barranquero]

On 12/29/06, Lennart Borgman (gmail) <lennart.borgman@gmail.com> wrote:

> Please explain a little bit more.

You're saying to users that (with your patch) it will work "more like
[it does] usually in MS Windows programs", not explaining why Emacs
does things differently, nor how (or why) that could be good. Little
wonder they prefer it "like MS Windows programs".

> You mean that they read my text that way? Yes, maybe the main reason is
> lack of agreement that these patches are really needed. Then what do you
> expect me to do?

I expect nothing. I'm explaining why I think the language on your page
is reason enough for people to choose your patched version.

> Though I am getting tired of
> saying things over and over again.

That's part of the process of convincing people and getting patches approved.

> What about that patch that tells
> Emacs to save the changes when a user logs off? I included that in my
> patched version nearly half a year ago since I did not want to loose my
> work. Is it included in Emacs today?

Why was not included? Was it deemed unnecessary, or wrong, or it just
fell off the wayside?

> The low level keyboard hook that allows Emacs to use the left and right
> windows keys as Emacs meta key should in my opinion be a very
> uncontroversial issue.

That's quite a weird claim. On one hand you're championing Windows UI
guidelines compliance; on the other, you want Emacs to steal one of
the Windows keys, which is an uncommon thing for Windows programs to
do. Win+R or Win+E do execute Run and Windows Explorer even if typed
inside Notepad or Microsoft Word.

> but it is hard for me to understand why it should be
> scary to use a low level keyboard hook.

I looked at your low-level hook code once; it wasn't scary. It was
just complex for little gain.

                    /L/e/k/t/u

Re: National Language Support Functions

[Lennart Borgman (gmail)]

Juanma Barranquero wrote:
> On 12/29/06, Lennart Borgman (gmail) <lennart.borgman@gmail.com> wrote:
>
>> Please explain a little bit more.
>
> You're saying to users that (with your patch) it will work "more like
> [it does] usually in MS Windows programs", not explaining why Emacs
> does things differently, nor how (or why) that could be good. Little
> wonder they prefer it "like MS Windows programs".

I explain (very short) in another place in the documentation for 
EmacsW32 why Emacs does it that way. I try to be short here, but if you 
have a better suggestion for how to write this please tell me.

> I expect nothing. I'm explaining why I think the language on your page
> is reason enough for people to choose your patched version.

I could be more neutral, you are right. But again, some help would be 
appreciated. Maybe there is a good neutral explanation and comparision 
somewhere on the net? I assume it must be written in a language that 
makes sense to new users who are used to MS Windows.

>
>> Though I am getting tired of
>> saying things over and over again.
>
> That's part of the process of convincing people and getting patches 
> approved.

That is good of course, but there is just too many, but perhaps rather 
small problem on the MS Windows side, unfortunately. Since MS Windows is 
not the main target this makes it problematic to convince people.

>
>> What about that patch that tells
>> Emacs to save the changes when a user logs off? I included that in my
>> patched version nearly half a year ago since I did not want to loose my
>> work. Is it included in Emacs today?
>
> Why was not included? Was it deemed unnecessary, or wrong, or it just
> fell off the wayside?

I think it just fell off the wayside. The reason? See above.


>
>> The low level keyboard hook that allows Emacs to use the left and right
>> windows keys as Emacs meta key should in my opinion be a very
>> uncontroversial issue.
>
> That's quite a weird claim. On one hand you're championing Windows UI
> guidelines compliance; on the other, you want Emacs to steal one of
> the Windows keys, which is an uncommon thing for Windows programs to
> do. Win+R or Win+E do execute Run and Windows Explorer even if typed
> inside Notepad or Microsoft Word.

What a you trying to say? That the ability to use those keys as meta 
should be ruled out because it brakes the Windows UI guidelines? If I 
had a better choice I would take it. But steeling Alt is a far worse 
thing than steeling the Windows keys. The use of the Alt key is even 
specified in some of the Accessibility guidelines. I do not think the 
Windows keys are.

>
>> but it is hard for me to understand why it should be
>> scary to use a low level keyboard hook.
>
> I looked at your low-level hook code once; it wasn't scary. It was
> just complex for little gain. 

There is simply no other way to do it. It as complex as it needs to be 
and as simple as it can be.

Re: National Language Support Functions

[Juanma Barranquero]

On 12/30/06, Lennart Borgman (gmail) <lennart.borgman@gmail.com> wrote:

> I could be more neutral, you are right. But again, some help would be
> appreciated.

I'm not talking about neutrality, nor asking you to be neutral. I'm
countering your argument that your patches are good for new users
*because* more people downloads your patched Emacs than the unpatched
Emacs you also distribute.

> Since MS Windows is
> not the main target this makes it problematic to convince people.

I don't think it is hard to convince people, for real problems.
Perhaps you perceive as problems things that not many people see as
such.

> I think it just fell off the wayside.

If you're so convinced it is a problem, you should push harder IMHO.

> What a you trying to say? That the ability to use those keys as meta
> should be ruled out because it brakes the Windows UI guidelines?

No. I'm saying that IMO your opinion in that regard is wrong: the
issue is not uncontroversial.

> But steeling Alt is a far worse
> thing than steeling the Windows keys.

I just happen to disagree. Stealing neither one seems bad to me.

> It as complex as it needs to be
> and as simple as it can be.

That's only true if you factor the gain out of the equation.

                    /L/e/k/t/u

Re: National Language Support Functions

[Lennart Borgman (gmail)]

Juanma Barranquero wrote:
> I'm not talking about neutrality, nor asking you to be neutral. I'm
> countering your argument that your patches are good for new users
> *because* more people downloads your patched Emacs than the unpatched
> Emacs you also distribute.

Of course I did not say that. What made you think that? All I said is 
that they seem to think it is good. You may of course be right that I 
have convinced them, but that was not my meaning.

>
>> Since MS Windows is
>> not the main target this makes it problematic to convince people.
>
> I don't think it is hard to convince people, for real problems.
> Perhaps you perceive as problems things that not many people see as
> such.

You may be right.

>
>> I think it just fell off the wayside.
>
> If you're so convinced it is a problem, you should push harder IMHO.

It may be that not many people except me think it is a problem loosing 
work when logging off. Perhaps they do not think of what they done once 
they logged off? Or maybe they never do.

>
>> What a you trying to say? That the ability to use those keys as meta
>> should be ruled out because it brakes the Windows UI guidelines?
>
> No. I'm saying that IMO your opinion in that regard is wrong: the
> issue is not uncontroversial.

Maybe you are right, but as far as I remember there was no one saying 
that it is very important to be able to use the Windows keys for example 
to start Explorer from inside Emacs. But I might be mistaken of course.

>
>> But steeling Alt is a far worse
>> thing than steeling the Windows keys.
>
> I just happen to disagree. Stealing neither one seems bad to me.

What about accessibility guidelines?

>
>> It as complex as it needs to be
>> and as simple as it can be.
>
> That's only true if you factor the gain out of the equation. 

Or if you include the gain IMO.

Re: National Language Support Functions

[Juanma Barranquero]

On 12/30/06, Lennart Borgman (gmail) <lennart.borgman@gmail.com> wrote:

> Of course I did not say that. What made you think that?

When asked about your distribution, you used as argument that more
people downloaded your patched Emacs than the unpatched one. What's
the purpose of that comment?

> It may be that not many people except me think it is a problem loosing
> work when logging off. Perhaps they do not think of what they done once
> they logged off? Or maybe they never do.

I certainly log off, and I've never lost data that way. Perhaps I'm
used to exiting Emacs (and other programs) before logging off. That's
not to say you're not pointing out a real problem (in fact, I've never
seen your patch, but a priori it seems like a good idea).

> Maybe you are right, but as far as I remember there was no one saying
> that it is very important to be able to use the Windows keys for example
> to start Explorer from inside Emacs. But I might be mistaken of course.

I fail to see the flood of complaints about Emacs' use of Alt, too.

> What about accessibility guidelines?

Important. Not a specific goal, AFAICS. I don't think use of alt is
the only problem in that regard. And remapping of keys for
accessibility reasons can (and perhaps should) be done outside Emacs,
with other tools.

                    /L/e/k/t/u

Re: National Language Support Functions

[Lennart Borgman (gmail)]

Juanma Barranquero wrote:
> On 12/30/06, Lennart Borgman (gmail) <lennart.borgman@gmail.com> wrote:
>
>> Of course I did not say that. What made you think that?
>
> When asked about your distribution, you used as argument that more
> people downloaded your patched Emacs than the unpatched one. What's
> the purpose of that comment?

To say that people seem to find the patches useful. But I agree with 
your argument that this is not an evidence at all.

>
> I certainly log off, and I've never lost data that way. Perhaps I'm
> used to exiting Emacs (and other programs) before logging off. That's
> not to say you're not pointing out a real problem (in fact, I've never
> seen your patch, but a priori it seems like a good idea).

I never close any program before shutting down. I hope they all behave 
according to the guidelines.

>
> I fail to see the flood of complaints about Emacs' use of Alt, too.

You did not notice my complaints? ;-)

Perhaps people do not complain, perhaps they just move on.

> Important. Not a specific goal, AFAICS. I don't think use of alt is
> the only problem in that regard. And remapping of keys for
> accessibility reasons can (and perhaps should) be done outside Emacs,
> with other tools.

Part of the accessibility guidelines is to not put a burdon on those 
that needs the help they should give.

That means that every program should follow them.

Re: National Language Support Functions

[Eli Zaretskii]

> Date: Sat, 30 Dec 2006 01:14:30 +0100
> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> >> The low level keyboard hook that allows Emacs to use the left and right
> >> windows keys as Emacs meta key should in my opinion be a very
> >> uncontroversial issue.
> >
> > That's quite a weird claim. On one hand you're championing Windows UI
> > guidelines compliance; on the other, you want Emacs to steal one of
> > the Windows keys, which is an uncommon thing for Windows programs to
> > do. Win+R or Win+E do execute Run and Windows Explorer even if typed
> > inside Notepad or Microsoft Word.
> 
> What a you trying to say? That the ability to use those keys as meta 
> should be ruled out because it brakes the Windows UI guidelines? If I 
> had a better choice I would take it.

So it's okay to break the praised ``Windows guidelines'' when _you_
think there's no better solution, but it is _not_ okay when others
think following those guidelines makes more harm than help?  That's a
funny way of presenting a coherent case, I'd say.

> > I looked at your low-level hook code once; it wasn't scary. It was
> > just complex for little gain. 
> 
> There is simply no other way to do it.

Then I say let's not do it at all.

Re: National Language Support Functions

[Lennart Borgman (gmail)]

Eli Zaretskii wrote:
> So it's okay to break the praised ``Windows guidelines'' when _you_
> think there's no better solution, but it is _not_ okay when others
> think following those guidelines makes more harm than help?  That's a
> funny way of presenting a coherent case, I'd say.
>   

I think you are unfortunately missing my argument. I want to give the 
users the alternative to use the left and right windows keys as meta.

The current code in Emacs does not allow the users to do that. The 
current discussion does not at all focus on this and it makes me a bit 
disappointed.

>   
>>> I looked at your low-level hook code once; it wasn't scary. It was
>>> just complex for little gain. 
>>>       
>> There is simply no other way to do it.
>>     
>
> Then I say let's not do it at all.
>   

Well, since it seems like no one else than me here want to achieve this 
agree then let us settle on this then.

I still have my opinion that it is a good idea to let the users have 
that choice and I do not think there are problems technically with 
allowing it, but I understand you standpoint. It does add complexity to 
add the code needed.

Re: National Language Support Functions

[Eli Zaretskii]

> Date: Sat, 30 Dec 2006 16:53:32 +0100
> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
> CC:  lekktu@gmail.com,  emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> > So it's okay to break the praised ``Windows guidelines'' when _you_
> > think there's no better solution, but it is _not_ okay when others
> > think following those guidelines makes more harm than help?  That's a
> > funny way of presenting a coherent case, I'd say.
> >   
> 
> I think you are unfortunately missing my argument.

I didn't miss your argument, I was reflecting on the _way_ you
_present_ your arguments.  If you say that some principle is
important, then please follow that principle even if it is
inconvenient for your own arguments.

> I want to give the 
> users the alternative to use the left and right windows keys as meta.

They don't have that alternative in other Windows programs, except by
remapping the keycodes.  I don't see why Emacs should be different.

Re: National Language Support Functions

[Lennart Borgman (gmail)]

Eli Zaretskii wrote:
> I didn't miss your argument, I was reflecting on the _way_ you
> _present_ your arguments.  If you say that some principle is
> important, then please follow that principle even if it is
> inconvenient for your own arguments.
>   

Indeed I do. I said you cannot follow the guidelines. I said some ways 
to diverge from them were worse than other ways.

> They don't have that alternative in other Windows programs, except by
> remapping the keycodes.  I don't see why Emacs should be different.
>   

My point is that Emacs should be different because it steeles the very 
important Alt key.

Re: National Language Support Functions

[Jason Rumney]

Lennart Borgman (gmail) wrote:
> Indeed I do. I said you cannot follow the guidelines. I said some ways 
> to diverge from them were worse than other ways.
Which is worse than the other is a matter of opinion, and judging by the 
use of the words IF, USUALLY and MUST in the snippets from the 
accessibility guidelines I have read, your opinion differs from the 
source you are claiming backs you up:

> Keyboard shortcuts can be found in the menus of programs, or, if a 
> letter is underlined on a menu, that usually means pressing the ALT 
> key in combination with the underlined key has the same effect as 
> clicking that menu item.
> An application must not affect any system-wide shortcut keys (a key or 
> a combination of keys used to perform a command), such as the Windows 
> logo key that opens the *Start* menu.

But what these guidelines say is not really important for considering 
what to do in Emacs. What is important is what users want, and what we 
can achieve technically. So far, the only patch I've seen submitted in 
this area swallowed the Windows logo keys so that neither Emacs nor 
Windows could see them, and there were other concerns that Eli and 
myself had regarding the removal of the low level hook when Emacs 
crashes, and the need to perform low level processing on many more keys 
in order to use those keys as modifiers, that have not been addressed as 
far as I am aware.

Re: National Language Support Functions

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> Lennart Borgman (gmail) wrote:
>> Indeed I do. I said you cannot follow the guidelines. I said some 
>> ways to diverge from them were worse than other ways.
> Which is worse than the other is a matter of opinion, and judging by 
> the use of the words IF, USUALLY and MUST in the snippets from the 
> accessibility guidelines I have read, your opinion differs from the 
> source you are claiming backs you up:
>
>> Keyboard shortcuts can be found in the menus of programs, or, if a 
>> letter is underlined on a menu, that usually means pressing the ALT 
>> key in combination with the underlined key has the same effect as 
>> clicking that menu item.
>> An application must not affect any system-wide shortcut keys (a key 
>> or a combination of keys used to perform a command), such as the 
>> Windows logo key that opens the *Start* menu.

I did not know that those guidelines from MS say that you must not 
steele the system-wide shortcut keys. I am not sure were I saw that 
about the Alt key, but I believe it was in the US accessibility 
guidelines. Well, I can only say Emacs have to break them in one way or 
the other.

>
> But what these guidelines say is not really important for considering 
> what to do in Emacs. What is important is what users want, and what we 
> can achieve technically. So far, the only patch I've seen submitted in 
> this area swallowed the Windows logo keys so that neither Emacs nor 
> Windows could see them, and there were other concerns that Eli and 
> myself had regarding the removal of the low level hook when Emacs 
> crashes, and the need to perform low level processing on many more 
> keys in order to use those keys as modifiers, that have not been 
> addressed as far as I am aware.
>
I agree that the important thing is what users want and what we can do. 
My patch is and has been available on my site for 1.5 yr. It is also 
included in the download when you download the patched version. (But it 
is not a separate patch.)

With this patch you can let Emacs use the Windows keys if you want, but 
you do not have to. You can let Emacs have one of them or both.

Note that other programs are not affected by this patch. I think there 
has been some misunderstandings about this before.

Re: National Language Support Functions

[Eli Zaretskii]

> Date: Sat, 30 Dec 2006 00:51:36 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> > but it is hard for me to understand why it should be
> > scary to use a low level keyboard hook.
> 
> I looked at your low-level hook code once; it wasn't scary. It was
> just complex for little gain.

When this issue was discussed, I explained why I thought it was a bad
idea; please re-read this message:

  http://lists.gnu.org/archive/html/emacs-devel/2005-07/msg00467.html

and the discussion that followed.

Re: National Language Support Functions

[Lennart Borgman (gmail)]

Eli Zaretskii wrote:
>> Date: Sat, 30 Dec 2006 00:51:36 +0100
>> From: "Juanma Barranquero" <lekktu@gmail.com>
>> Cc: emacs-devel@gnu.org
>>
>>     
>>> but it is hard for me to understand why it should be
>>> scary to use a low level keyboard hook.
>>>       
>> I looked at your low-level hook code once; it wasn't scary. It was
>> just complex for little gain.
>>     
>
> When this issue was discussed, I explained why I thought it was a bad
> idea; please re-read this message:
>
>   http://lists.gnu.org/archive/html/emacs-devel/2005-07/msg00467.html
>
> and the discussion that followed.
>   

Did not I explain why that argument is not valid here? If you take a 
look at the code you will see that very little will have to change to 
allow this hook.

Re: National Language Support Functions

[Eli Zaretskii]

> Date: Sat, 30 Dec 2006 16:21:14 +0100
> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
> CC: Juanma Barranquero <lekktu@gmail.com>,  emacs-devel@gnu.org
> >
> >   http://lists.gnu.org/archive/html/emacs-devel/2005-07/msg00467.html
> >
> > and the discussion that followed.
> 
> Did not I explain why that argument is not valid here?

You said:

  "I would not suggest using it if I believed that."

This hardly qualifies as explaining why my argument ``is not valid''.

> If you take a look at the code you will see that very little will
> have to change to allow this hook.

What I said back then had nothing to do with how easy or hard is it to
allow your hook.  I was talking about long-term maintenance burden,
not short-term amount of work.

Re: National Language Support Functions

[Lennart Borgman (gmail)]

Eli Zaretskii wrote:
>> Date: Sat, 30 Dec 2006 16:21:14 +0100
>> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
>> CC: Juanma Barranquero <lekktu@gmail.com>,  emacs-devel@gnu.org
>>     
>>>   http://lists.gnu.org/archive/html/emacs-devel/2005-07/msg00467.html
>>>
>>> and the discussion that followed.
>>>       
>> Did not I explain why that argument is not valid here?
>>     
>
> You said:
>
>   "I would not suggest using it if I believed that."
>
> This hardly qualifies as explaining why my argument ``is not valid''.
>   

I can not see why you think that is the explanation?

Instead of explaining it all myself I gave you some links to other pages 
that described the situation.

>   
>> If you take a look at the code you will see that very little will
>> have to change to allow this hook.
>>     
>
> What I said back then had nothing to do with how easy or hard is it to
> allow your hook.  I was talking about long-term maintenance burden,
> not short-term amount of work.
>   

Yes, that is true and a very good argument. I just happen to disagree on 
the amount of maintenance burden.

Re: National Language Support Functions

[Richard Stallman]

    Yes, getting starting compiling was a big problem, but now I have 
    everything setup and it is very easy to compile and upload. I just type 
    "doit". The unpatched version I do not test at all.

This practice means you are not helping us any more.

Re: National Language Support Functions

[Lennart Borgman (gmail)]

Richard Stallman wrote:
>     Yes, getting starting compiling was a big problem, but now I have 
>     everything setup and it is very easy to compile and upload. I just type 
>     "doit". The unpatched version I do not test at all.
>
> This practice means you are not helping us any more.
>   
Hm. I follow my own advice on my web site. As soon as I find a bug I 
switch to the unpatched version. I just do not test it before I make it 
available to other people.