bootstrap failed on Windows XP
--8<---cut here---start->8--- D:\download\emacs-gbk\nt>configure --with-gcc --no-cygwin --no-debug Checking for 'cp'... Checking for 'rm'... 系统找不到指定的文件。 Checking whether W32 API headers are too old... D:\download\emacs-gbk\nt>gcc -mno-cygwin -c junk.c Using 'gcc' Checking for libpng... ...PNG header available, building with PNG support. Checking for jpeg-6b... ...JPEG header available, building with JPEG support. Checking for libgif... ...GIF header available, building with GIF support. Checking for tiff... ...TIFF header available, building with TIFF support. Checking for libXpm... ...XPM header available, building with XPM support. Generating makefiles 已复制 1 个文件。 config.settings gmake.defs ..\nt\makefile.w32-in 已复制 1 个文件。 config.settings gmake.defs ..\lib-src\makefile.w32-in 已复制 1 个文件。 config.settings gmake.defs ..\src\makefile.w32-in 已复制 1 个文件。 config.settings gmake.defs ..\man\makefile.w32-in 已复制 1 个文件。 config.settings gmake.defs ..\lispref\makefile.w32-in 已复制 1 个文件。 config.settings gmake.defs ..\lispintro\makefile.w32-in 已复制 1 个文件。 config.settings gmake.defs ..\lisp\makefile.w32-in 已复制 1 个文件。 config.settings gmake.defs ..\leim\makefile.w32-in 已复制 1 个文件。 Emacs successfully configured. Run `gmake' to build, then run `gmake install' to install. D:\download\emacs-gbk\nt>make bootstrap mkdir "oo-spd" mkdir "oo-spd/i386" echo oo-spd/i386 > stamp_BLD ', needed by `addsection'. Stop.`oo-spd/i386/addsection.exe D:\download\emacs-gbk\nt> --8<---cut here---end--->8--- If Emacs crashed, and you have the Emacs process in the gdb debugger, please include the output from the following gdb commands: `bt full' and `xbacktrace'. If you would like to further debug the crash, please read the file c:/Emacs/etc/DEBUG for instructions. In GNU Emacs 22.0.92.1 (i386-mingw-nt5.1.2600) of 2006-12-22 on BREP X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.2)' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: CHS locale-coding-system: cp936 default-enable-multibyte-characters: t Major mode: Group Minor modes in effect: gnus-topic-mode: t gnus-undo-mode: t shell-dirtrack-mode: t auto-image-file-mode: t display-time-mode: t show-paren-mode: t delete-selection-mode: t pc-selection-mode: t encoded-kbd-mode: t tooltip-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t Recent input: C-y C-@ C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-w C-x C-b g M-x r e p o r t - e m a Recent messages: Commands: m, u, t, RET, g, k, S, D, Q; q to quit; h for help Mark set [2 times] Updating buffer list...done Commands: m, u, t, RET, g, k, S, D, Q; q to quit; h for help Checking new news... nnml: Reading incoming mail from pop... nnml: Reading incoming mail (no new mail)...done Checking new news...done No gnus is bad news Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
[bug] Gnus weird behavior
Hi all, To reproduce: - go to the article buffer - click the right arrow in the toolbar Backtrace: , | Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil) | gnus-summary-next-article(nil) | call-interactively(gnus-summary-next-article) ` BTW, left arrow does not have this problem. -- Leo (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: National Language Support Functions
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 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
Chris Moore wrote: Personally I always found that all the spaces in directory names on a Windows box breaks shell-mode completion anyway. It's been a while since I used Windows, but doesn't it act something like this: cd /Docum cd /Documents and Settings/chr no such file or directory: /Settings/ Actually it works with cmd/cmdproxy shell (with that little change we are discussing, but it is broken with both MSYS and Cygwin as inferior shells. With Cygwin I get the behaviour above. With MSYS I get some very strange problems: MSYS /c > dir Pr<*> MSYS /c > dir Pr] If I try to enter * (see above) I get a ]. Quite strange. It only happens inside Emacs. MSYS /c > dir Pr In minibuffer: Partially completed MSYS /c > dir (the listing does not contain Program Files, but it should as far as I can see) MSYS /c > pwd /c ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Value menu value should be listed on a separate line
> >> > When a value menu is present, the current value should be on a > >> > separate line from the Value Menu button. Currently, the > current value > >> > is listed next to the Value Menu button, which makes the Customize > >> > buffer far too wide. > >> > >>The author of an option is responsible for its appearance. > > > > > > Uh, how is the author supposed to start a value that has a tag > > on a separate line? > > Usually with ":entry-format" and ":format". No special formatting should be necessary, just to be able to use a simple tag. I don't believe that was why :*format were introduced. > > Writers of defcustom's shouldn't need to concern themselves > > with the layout > > of the Customize buffer, anyway. They should be able to define > > a :tag string > > without the preoccupation of its starting position and the number of > > characters already taken up by the option name and the button widths. > > I'm convinced that writers of defcustoms should care about the layout. OK, you're convinced. I said that they should not *need* to concern themselves with the layout of stuff, beyond their own creations. This is a flaw in the basic layout, which should not be shoved off onto the definers of individual values, to work around. It should be trivial to fix, no less - why not fix the general case, instead of making writers of each value work around it over and over? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: customize options and faces are not in alphabetical order
> > - They are apparently not autoloaded, so `C-h v' doesn't recognize them > > until customize has been loaded. > > How can `C-h v' help you to find something you're not aware of? That's not the point. The point is that these should be well documented, and autoloaded so you can get to the documentation. However, C-h v can easily help you find something you are not aware of, by showing you what's available with completion. I do it every day. > > - None are mentioned in the Emacs manual (or the Elisp manual, for that > > matter), so a user is unlikely to know about them. > > They are customizable, so users should be able to find them. Why would they look for them if they are not aware of them, to use your logic? > > - What is the difference between them, besides the fact that > > they are in > > different subgroups of the Customize group? They have identical doc > > strings - how is a user to understand their difference? What > > is the scope of > > the sorting (where are the members sorted)? Why are there 3 > > separate options > > for this, if they all do the same thing (same doc string)? > > This should be improved. Agreed. > > - Why would the default value of any of these be nil (off)? If > > the nil order > > is (apparently) random, how does that benefit anyone as the > > default value? > > The "nil" order is the one chosen by the designer of the option. Emacs maintainers are now responsible. I don't know what the designer's rationale was, and I don't see a good rationale. I was asking if there is one. > > I don't understand why we would even have such options - who > > would ever want a random order? > > Why do you think it's random? I said "apparently". I have no idea what determines the order. It is not an obvious, understandable, or obviously useful order. I don't care if it's actually random. I asked if there was a good reason for it, and you essentially told me to go ask the designer. > > A better idea, if really we want to allow users flexibility in > > the order, is > > to use a sort function as the customizable value, and have > > `string-lessp' be > > the default value. If you want to allow unsorted (random), > > then use this: > > > > (defcustom custom-sort-alphabetically 'string-lessp > > "Sort function for Customize buffers. > > Do not sort if the value is nil. > > :type '(choice (const :tag "None" nil) function)) > > > > I personally don't see why anyone would want an order other > > than alphabetic, > > but at least that would be a reasonable way to give people a > > choice. The > > current approach does not seem useful. > > It would give people the inverse choice, not fundamentally different > though. Fundamentally different: they could supply any sort function. Now they have a choice between string-lessp and nil, that's all. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Value menu value should be listed on a separate line
>> > When a value menu is present, the current value should be on a >> > separate line from the Value Menu button. Currently, the current value >> > is listed next to the Value Menu button, which makes the Customize >> > buffer far too wide. >> >>The author of an option is responsible for its appearance. > > > Uh, how is the author supposed to start a value that has a tag on a separate > line? Usually with ":entry-format" and ":format". > Writers of defcustom's shouldn't need to concern themselves with the layout > of the Customize buffer, anyway. They should be able to define a :tag string > without the preoccupation of its starting position and the number of > characters already taken up by the option name and the button widths. I'm convinced that writers of defcustoms should care about the layout. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: customize options and faces are not in alphabetical order
> Thx - I wasn't aware of those. > > However: > > - They are apparently not autoloaded, so `C-h v' doesn't recognize them > until customize has been loaded. How can `C-h v' help you to find something you're not aware of? > - None are mentioned in the Emacs manual (or the Elisp manual, for that > matter), so a user is unlikely to know about them. They are customizable, so users should be able to find them. > - What is the difference between them, besides the fact that they are in > different subgroups of the Customize group? They have identical doc > strings - how is a user to understand their difference? What is the scope of > the sorting (where are the members sorted)? Why are there 3 separate options > for this, if they all do the same thing (same doc string)? This should be improved. > - Why would the default value of any of these be nil (off)? If the nil order > is (apparently) random, how does that benefit anyone as the default value? The "nil" order is the one chosen by the designer of the option. > I don't understand why we would even have such options - who would ever want > a random order? Why do you think it's random? > A better idea, if really we want to allow users flexibility in the order, is > to use a sort function as the customizable value, and have `string-lessp' be > the default value. If you want to allow unsorted (random), then use this: > > (defcustom custom-sort-alphabetically 'string-lessp > "Sort function for Customize buffers. > Do not sort if the value is nil. > :type '(choice (const :tag "None" nil) function)) > > I personally don't see why anyone would want an order other than alphabetic, > but at least that would be a reasonable way to give people a choice. The > current approach does not seem useful. It would give people the inverse choice, not fundamentally different though. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Value menu value should be listed on a separate line
> > When a value menu is present, the current value should be on a > > separate line from the Value Menu button. Currently, the current value > > is listed next to the Value Menu button, which makes the Customize > > buffer far too wide. > > The author of an option is responsible for its appearance. Uh, how is the author supposed to start a value that has a tag on a separate line? If you have a :tag, you have a :tag. Here's an example: (defcustom foo 'foo1 "*Whatever" :type `(choice (const :tag "This is a 70-char string describing this value" foo1) (const :tag "Another substantially long string" foo2)) :group 'mygroup) The :tag of the default value, foo1, is displayed to the right of the Value Menu button, after a space. Tell me how to avoid that, and have it be displayed on the next line, starting at column 1. Depending on the number of chars in the option name, the column after the Value Menu button might easily be near 70, just to start with. To that is added the length of the :tag string. Writers of defcustom's shouldn't need to concern themselves with the layout of the Customize buffer, anyway. They should be able to define a :tag string without the preoccupation of its starting position and the number of characters already taken up by the option name and the button widths. > > Tags for menu items are generally less than 81 > > characters wide. Putting the value (tag) on a separate line would mean > > that the entire buffer would generally be no more than 80 chars > > wide. Currently, a buffer with a 70-char value has a width of about > > 134. > > This should be decided for each option individually. How? See above. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: customize options and faces are not in alphabetical order
> From: martin rudalics > > emacs -Q > > M-x customize > > > > The options and faces should be in alphabetical order. The actual > > order seems random. > > Should be possible: > > (defcustom custom-browse-sort-alphabetically nil >"If non-nil, sort members of each customization group alphabetically." >:type 'boolean >:group 'custom-browse) > > (defcustom custom-buffer-sort-alphabetically nil >"If non-nil, sort members of each customization group alphabetically." >:type 'boolean >:group 'custom-buffer) > > (defcustom custom-menu-sort-alphabetically nil >"If non-nil, sort members of each customization group alphabetically." >:type 'boolean >:group 'custom-menu) Thx - I wasn't aware of those. However: - They are apparently not autoloaded, so `C-h v' doesn't recognize them until customize has been loaded. - None are mentioned in the Emacs manual (or the Elisp manual, for that matter), so a user is unlikely to know about them. - What is the difference between them, besides the fact that they are in different subgroups of the Customize group? They have identical doc strings - how is a user to understand their difference? What is the scope of the sorting (where are the members sorted)? Why are there 3 separate options for this, if they all do the same thing (same doc string)? - Why would the default value of any of these be nil (off)? If the nil order is (apparently) random, how does that benefit anyone as the default value? I don't understand why we would even have such options - who would ever want a random order? A better idea, if really we want to allow users flexibility in the order, is to use a sort function as the customizable value, and have `string-lessp' be the default value. If you want to allow unsorted (random), then use this: (defcustom custom-sort-alphabetically 'string-lessp "Sort function for Customize buffers. Do not sort if the value is nil. :type '(choice (const :tag "None" nil) function)) I personally don't see why anyone would want an order other than alphabetic, but at least that would be a reasonable way to give people a choice. The current approach does not seem useful. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Value menu value should be listed on a separate line
> When a value menu is present, the current value should be on a > separate line from the Value Menu button. Currently, the current value > is listed next to the Value Menu button, which makes the Customize > buffer far too wide. The author of an option is responsible for its appearance. > Tags for menu items are generally less than 81 > characters wide. Putting the value (tag) on a separate line would mean > that the entire buffer would generally be no more than 80 chars > wide. Currently, a buffer with a 70-char value has a width of about > 134. This should be decided for each option individually. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: customize options and faces are not in alphabetical order
> emacs -Q > M-x customize > > The options and faces should be in alphabetical order. The actual > order seems random. Should be possible: (defcustom custom-browse-sort-alphabetically nil "If non-nil, sort members of each customization group alphabetically." :type 'boolean :group 'custom-browse) (defcustom custom-buffer-sort-alphabetically nil "If non-nil, sort members of each customization group alphabetically." :type 'boolean :group 'custom-buffer) (defcustom custom-menu-sort-alphabetically nil "If non-nil, sort members of each customization group alphabetically." :type 'boolean :group 'custom-menu) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Value menu value should be listed on a separate line
emacs -Q M-x customize When a value menu is present, the current value should be on a separate line from the Value Menu button. Currently, the current value is listed next to the Value Menu button, which makes the Customize buffer far too wide. Tags for menu items are generally less than 81 characters wide. Putting the value (tag) on a separate line would mean that the entire buffer would generally be no more than 80 chars wide. Currently, a buffer with a 70-char value has a width of about 134. In GNU Emacs 22.0.91.1 (i386-mingw-nt5.1.2600) of 2006-12-11 on LENNART-69DE564 X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Id:/g/include' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: ENU locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Dired by name Minor modes in effect: encoded-kbd-mode: t tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: Recent messages: (C:\Emacs-22-2006-12-11-Lennart\bin\emacs.exe -q --no-site-file --debug-init C:\drews-lisp-20) Loading encoded-kb...done For information about the GNU Project and its goals, type C-h C-p. Loading dired... Loading regexp-opt...done Loading dired...done For information about the GNU Project and its goals, type C-h C-p. Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
customize options and faces are not in alphabetical order
emacs -Q M-x customize The options and faces should be in alphabetical order. The actual order seems random. In GNU Emacs 22.0.91.1 (i386-mingw-nt5.1.2600) of 2006-12-11 on LENNART-69DE564 X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Id:/g/include' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: ENU locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Dired by name Minor modes in effect: encoded-kbd-mode: t tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: Recent messages: (C:\Emacs-22-2006-12-11-Lennart\bin\emacs.exe -q --no-site-file --debug-init C:\drews-lisp-20) Loading encoded-kb...done For information about the GNU Project and its goals, type C-h C-p. Loading dired... Loading regexp-opt...done Loading dired...done For information about the GNU Project and its goals, type C-h C-p. Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs Manual: G.5 Keyboard Usage on MS-Windows
> From: Richard Stallman <[EMAIL PROTECTED]> > CC: [EMAIL PROTECTED], [EMAIL PROTECTED], > emacs-pretest-bug@gnu.org > Date: Fri, 22 Dec 2006 16:03:12 -0500 > > Yes, probably. Btw, that place ("Symbol Completion") already mentions > possible problems with window managers. > > In that case, is there anything more to change? Perhaps an xref from the Windows appendix to "Symbol Completion"? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs Manual: G.5 Keyboard Usage on MS-Windows
Yes, probably. Btw, that place ("Symbol Completion") already mentions possible problems with window managers. In that case, is there anything more to change? Lennart wrote: Once again: I think it is important that it stands out. You should not have to search for explanation of this problem as a beginner. Then you may just think that something is seriously wrong. Keep it as simple as possible for beginners because. That makes it much easier for them to learn. As a general request, I agree; but unless someone can suggest a specific change to make, we can't make one. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Broken "C-b remapped to ..." advice in tutorial.
2. Displaying one line of warning message for each rebound key sequence is really annoying. We should just highlight them in a different face and display the message in a tooltip, and/or when the text is clicked on. After all, there is already a big warning message at the top of the tutorial page saying keys have been rebound; no need to hammer it in. I do not really understand what you are proposing here. We considered many approaches here, and of them, this is the one I like best. I am not inclined to change it again. However, if you give a clear (not terse) description of an alternative, I'll consider it. 3. The tutorial-position saving mechanism is very opaque. When the buffer is killed, the current position in the tutorial, without prompting the user (it used to save into a directory ~/.emacstut, but I moved this into .emacs.d to avoid homedir pollution). However, this saving does not occur if the user does C-x C-c or C-x C-s. I agree it should be made to work on C-x C-c. That should be easy, right? There is no need for saving the buffer to do this, though. If you kill the buffer, the position will be saved; if not, it need not be saved because it is still in the buffer. This feature is confusing enough that I'd propose removing it entirely. It is useful, and I don't want to remove it. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
Eli Zaretskii <[EMAIL PROTECTED]> writes: > You can try mocking my preferences till Kingdom Come, but they are > still _my_ preferences, and I didn't impose them on anyone else. I'm not mocking your preferences; sorry that you thought I was. I didn't realise you were saying it should be a preference - I thought you were arguing that the way it currently is in Emacs is acceptable, ie. hitting tab completes directory names with a /, even when you're on Windows. > Anyway, I guess you've never used keyboard enhancement programs that > make such rewrites seamlessly and transparently. No, I've not. > For people who routinely work on both Windows and Unix, this is a > sanity-savior. Personally I always found that all the spaces in directory names on a Windows box breaks shell-mode completion anyway. It's been a while since I used Windows, but doesn't it act something like this: cd /Docum cd /Documents and Settings/chr no such file or directory: /Settings/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
python-mode.el doesn't associate python-mode with .PY files
I'm browsing some old Python sources on a CD, and they're all opening in fundamental-mode instead of python-mode. All the filenames on the CD are in uppercase. Perhaps python-mode.el could be modified to recognise .PY files as well as .py files as containing Python code? I've not tried opening any Perl sources yet, but when I do I'll be sure to check that they open with the correct mode. In GNU Emacs 22.0.91.34 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2006-12-19 on chrislap X server distributor `RealVNC Ltd', version 11.0.3370 configured using `configure '--with-gtk' '--prefix' '/usr/local/emacs22' '--with-xpm' '--with-jpeg' '--with-png' '--with-gif'' Important settings: value of $LC_ALL: en_GB.UTF-8 value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_GB.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: National Language Support Functions
> Date: Fri, 22 Dec 2006 17:34:14 +0100 > From: Lennart Borgman <[EMAIL PROTECTED]> > CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org > > Eli Zaretskii wrote: > > On my system, I get this from your program: > > > > LangID = SYS: 0x40d, USR: 0x409 > > LCID = SYS: 0x40d, USR: 0x409 > > GetUserDefaultUILanguage() = 0409 > > GetSystemDefaultUILanguage = 0409 > > > > This is Windows XP SP2, with the following Regional Settings: > > > > . In the Regional Options tab: > > . In "Standard and formats": English (United States) > > . In "Location": Israel > > . In the Languages tab: > > . Clicking on Details shows: > > . In the Settings tab: > > . Default input language: English (United States) - US > > . In the Advanced tab: > > . Every check box is unchecked > > . In the Advanced tab: > > . Language for non-Unicode programs: Hebrew > > > What language are your menus etc in on this pc? English. > What is the last option actually used for? Is that the choice of > character set for output of non-unicode or? I'm not sure, but I think it is used for programs that use ANSI APIs for strings. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: National Language Support Functions
> Cc: emacs-pretest-bug@gnu.org, emacs-devel@gnu.org, >Lennart Borgman <[EMAIL PROTECTED]> > From: Benjamin Riefenstahl <[EMAIL PROTECTED]> > 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? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: National Language Support Functions
Eli Zaretskii wrote: Date: Fri, 22 Dec 2006 12:57:02 + From: Jason Rumney <[EMAIL PROTECTED]> Cc: Eli Zaretskii <[EMAIL PROTECTED]>, 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? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Manual: indexes are missing links
Eli Zaretskii <[EMAIL PROTECTED]> writes: > As Jury corrected me, the problem is not with supporting the new > format, the problem was that menus in the indices were not decorated > as normal menus since long ago. > > I agree that we should consider revising this decision now, that the > machines are so much faster. OK; I turned it on. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
.eps in image mode
CVS head C-x C-f a.eps open a new eps file %!PS-Adobe-2.0 input eps head in the first line C-x C-sSave and C-x k RET Close C-x C-f a.eps open it again, then a.eps is in Image mode. Actually, if beginning with "%!PS", any file will be image mode. -- Harbin Institute of Technology, China. Wang Chunyu . ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: National Language Support Functions
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 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: National Language Support Functions
Eli Zaretskii wrote: On my system, I get this from your program: LangID = SYS: 0x40d, USR: 0x409 LCID = SYS: 0x40d, USR: 0x409 GetUserDefaultUILanguage() = 0409 GetSystemDefaultUILanguage = 0409 This is Windows XP SP2, with the following Regional Settings: . In the Regional Options tab: . In "Standard and formats": English (United States) . In "Location": Israel . In the Languages tab: . Clicking on Details shows: . In the Settings tab: . Default input language: English (United States) - US . In the Advanced tab: . Every check box is unchecked . In the Advanced tab: . Language for non-Unicode programs: Hebrew What language are your menus etc in on this pc? What is the last option actually used for? Is that the choice of character set for output of non-unicode or? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: National Language Support Functions
Juanma Barranquero wrote: On 12/22/06, Eli Zaretskii <[EMAIL PROTECTED]> wrote: What are the manifestations of your use of English on this pc? If, as you say, ``keyboard, numbers, currencies, times, time zone and dates are Swedish'', then what aspects of the UI are English? Perhaps the UI, I mean: system messages, menus, etc. I know I've used quite a few times US releases of Windows so my whole interface was English, but the regional settings (keyboard, numbers, times, etc.) were set to Spain / Castillian Spanish. Yes, that is how my pc is setup at work. I guess something like that is what most people use in the Swedish sites of my company. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Gratuitous user interface change risks losing user work
> "Gregory" == Gregory Stark <[EMAIL PROTECTED]> writes: Gregory> On that note I was wondering if there was any option to have emacs Gregory> make more backup files. It seems it only does so when I first save Gregory> the file after visiting it. But I normally only start a new Emacs Gregory> when it crashes or I have to reboot my machine which isn't very Gregory> often. So I end up without many backup files. It's all documented in the emacs manual under "backup". Toto -- Contact information and PGP key at http://www-users.rwth-aachen.de/thorsten.bonow "The Prius is so slow, the child could run on the street, retrieve the ball and grow to puberty before you actually hit it." Jeremy Clarkson, Topgear ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Gratuitous user interface change risks losing user work
"Chris Moore" <[EMAIL PROTECTED]> writes: > Gregory Stark <[EMAIL PROTECTED]> writes: > >> This is awful. I just lost several days of work > > When you typed 'yes' and hit return to say you wanted to save your > work, Emacs will have made a backup of the file you were overwriting > in ~. No, it didn't; I looked. The latest backup file I had was a couple weeks old. On that note I was wondering if there was any option to have emacs make more backup files. It seems it only does so when I first save the file after visiting it. But I normally only start a new Emacs when it crashes or I have to reboot my machine which isn't very often. So I end up without many backup files. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
> Cc: Lennart Borgman <[EMAIL PROTECTED]>, > emacs-pretest-bug@gnu.org > From: Chris Moore <[EMAIL PROTECTED]> > Date: Fri, 22 Dec 2006 13:52:19 +0100 > > Eli Zaretskii <[EMAIL PROTECTED]> writes: > > > Personally, I _never_ want to see backslashes, even when I work in > > CMD. It makes me saner, since I happen to work simultaneously on > > Unix and on Windows. I'm sure I'm not the only one. > > Compare: > > "Personally, I never want to see those funny accent characters over the > letters when I type in Czech. I work simultaneously in English and > Czech, and the accents confuse me. Let cmdproxy insert the accents > for me". You can try mocking my preferences till Kingdom Come, but they are still _my_ preferences, and I didn't impose them on anyone else. Arguing about personal preferences, like about taste, is futile and counter-productive. I clearly wrote that the character used in completion should be a *user option*. So if you want, you can set that character to the Czech accent, it's fine with me. > If cmdproxy is changed to re-write dir commands, you'll be breaking > things for people who expect dir to work like dir works in a regular > cmd.exe window Read my lips: it should be a user option. No one will have anything broken if they don't want this. Anyway, I guess you've never used keyboard enhancement programs that make such rewrites seamlessly and transparently. For people who routinely work on both Windows and Unix, this is a sanity-savior. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: National Language Support Functions
> Date: Fri, 22 Dec 2006 12:57:02 + > From: Jason Rumney <[EMAIL PROTECTED]> > Cc: Eli Zaretskii <[EMAIL PROTECTED]>, 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. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Broken "C-b remapped to ..." advice in tutorial.
[EMAIL PROTECTED] (Kim F. Storm) writes: >> 1. There's no call for a special tutorial--tab-map to tab between >>warning messages. Why bother? > > Seems superfluous to me too. The tutorial shouldn't bind any keys > to have non-standard behavior! I removed it. >> 2. Displaying one line of warning message for each rebound key >>sequence is really annoying. We should just highlight them in a >>different face and display the message in a tooltip, and/or when >>the text is clicked on. After all, there is already a big warning >>message at the top of the tutorial page saying keys have been >>rebound; no need to hammer it in. > > Indeed. It should only give each warning once ... and just have > a tool-tip on other occurrences. I implemented this, too. >> 3. The tutorial-position saving mechanism is very opaque. When the >>buffer is killed, the current position in the tutorial, without >>prompting the user (it used to save into a directory ~/.emacstut, >>but I moved this into .emacs.d to avoid homedir pollution). >>However, this saving does not occur if the user does C-x C-c or C-x >>C-s. This feature is confusing enough that I'd propose removing it >>entirely. > > I was confused at first, but I don't know what is best. I added a prompt to ask if the user wants to save the tutorial state. That should be sufficient. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Broken "C-b remapped to ..." advice in tutorial.
>> I checked in a fix. > > Which doesn't quite work ... > > Try this: > > emacs -Q > (global-set-key "\C-b" 'ignore) > (global-set-key "\C-f" 'ignore) > C-h t > > It stops half-through with a "text is read-only" error . Should be fixed now. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
isearch-forward-regexp and isearch-backward-regexp return differing search results
emacs -D -Q please insert something in the line of hans ooffoo ooffoo ooffoo hans hans ooffoo ooffoo ooffoo hans and do a "C-M-r" search for "o.*o", repeat possibly the search and change to "C-M-s". You will see that the search results are very different. Some days ago I asked on gnu.emacs.help whether there is a reason for this behaviour. I think one would expect the same search results in forward and backward direction. In GNU Emacs 22.0.92.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2006-12-22 on hans X server distributor `The X.Org Foundation', version 11.0.60802000 Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: fr_FR.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Group Minor modes in effect: display-time-mode: t gnus-topic-mode: t gnus-undo-mode: t shell-dirtrack-mode: t auto-insert-mode: t show-paren-mode: t minibuffer-indicate-depth-mode: t delete-selection-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t abbrev-mode: t Recent input: M-> n n n C-M-k SPC n SPC SPC SPC < SPC SPC SPC q g M-< n C-n C-n C-n C-n E q L C-n C-n C-n M-> C-p C-p q n nC-M-k q M-< n n n q M-x e m a c s - b u b u g r e p o r b Recent messages: No more unread articles Mark set Retrieving newsgroup: nnml+private:mail.dalug... Fetching headers for nnml+private:mail.dalug...done Scoring...done Generating summary...done Expiring articles...done Auto-saving... Making completion list... [2 times] Loading emacsbug...done -- Best wishes H. Dieter Wilhelm Darmstadt, Germany ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: National Language Support Functions
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. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: National Language Support Functions
First program: SYS: 0xc0a, USR: 0xc0a Second program: LangID = SYS: 0xc0a, USR: 0xc0a LCID = SYS: 0xc0a, USR: 0xc0a GetUserDefaultUILanguage() = 0C0A GetSystemDefaultUILanguage = 0C0A Setup: Regional Options: "Standard and formats": Spanish (Spain) "Location": Spain Languages: Details: Settings: Default input language: Spanish (international sort) - Spanish Advaced tab: Second checkbox checked. Advanced: Language for non-Unicode programs: Spanish - Spain /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
Eli Zaretskii <[EMAIL PROTECTED]> writes: > Personally, I _never_ want to see backslashes, even when I work in > CMD. It makes me saner, since I happen to work simultaneously on > Unix and on Windows. I'm sure I'm not the only one. Compare: "Personally, I never want to see those funny accent characters over the letters when I type in Czech. I work simultaneously in English and Czech, and the accents confuse me. Let cmdproxy insert the accents for me". When you're typing "dir" commands, backslashes are for separating directories and forward slashes are for introducing options - this will list \p page by page: dir \p/p If cmdproxy is changed to re-write dir commands, you'll be breaking things for people who expect dir to work like dir works in a regular cmd.exe window, just like I'd be breaking Czech support for native Czech speakers with my proposed language mangling. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: National Language Support Functions
Eli Zaretskii wrote: Date: Fri, 22 Dec 2006 01:11:01 +0100 From: Lennart Borgman <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED] 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. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: National Language Support Functions
On 12/22/06, Eli Zaretskii <[EMAIL PROTECTED]> wrote: What are the manifestations of your use of English on this pc? If, as you say, ``keyboard, numbers, currencies, times, time zone and dates are Swedish'', then what aspects of the UI are English? Perhaps the UI, I mean: system messages, menus, etc. I know I've used quite a few times US releases of Windows so my whole interface was English, but the regional settings (keyboard, numbers, times, etc.) were set to Spain / Castillian Spanish. /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: National Language Support Functions
> Date: Fri, 22 Dec 2006 12:24:43 +0100 > From: LENNART BORGMAN <[EMAIL PROTECTED]> > Cc: Eli Zaretskii <[EMAIL PROTECTED]> > > From: Jason Rumney <[EMAIL PROTECTED]> > Date: Friday, December 22, 2006 11:48 am > Subject: Re: National Language Support Functions > > > Lennart Borgman wrote: 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: > > > > > So did you actually test it? > > > > What were your results? > > On the pc where I first noticed the problem I get: > > LangID = SYS: 0x41d, USR: 0x41d > LCID = SYS: 0x41d, USR: 0x41d > GetUserDefaultUILanguage() = 0409 > GetSystemDefaultUILanguage = 0409 > > The last two lines is what I expected. This was the pc where I get the > tutorial in Swedish. I think it would be very good if we fixed it. I guess > the code in Emacs also can serve as an example for other developers trying to > make the same thing. > > With LangID and LCID it seems more complicated probably because there are > many ways to set up the different parts of the international and regional > settings on a certain w32 pc. > > I will send more output later today. The last two lines always shows the > right thing, but the output from the first two gives mixed results. On my system, I get this from your program: LangID = SYS: 0x40d, USR: 0x409 LCID = SYS: 0x40d, USR: 0x409 GetUserDefaultUILanguage() = 0409 GetSystemDefaultUILanguage = 0409 This is Windows XP SP2, with the following Regional Settings: . In the Regional Options tab: . In "Standard and formats": English (United States) . In "Location": Israel . In the Languages tab: . Clicking on Details shows: . In the Settings tab: . Default input language: English (United States) - US . In the Advanced tab: . Every check box is unchecked . In the Advanced tab: . Language for non-Unicode programs: Hebrew ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: National Language Support Functions
> Date: Fri, 22 Dec 2006 10:34:55 +0100 > From: Lennart Borgman <[EMAIL PROTECTED]> > CC: Eli Zaretskii <[EMAIL PROTECTED]> > > Part of the trouble in this special case seems to be a mistake in the > specification from the beginning. Keyboard language and UI language were > treated as the same thing which they obviously not are for very many > computer users. What are the manifestations of the UI language, besides the keyboard input language? > In ms last update in this area I can see they are getting still a > bit closer to reality. No, they just introduced a few more functions whose functionality overlaps the old ones, and this whole mess is so badly documented that it's impossible to understand how each language is chosen and by whom, and what is the right language to use in each situation. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: National Language Support Functions
> Date: Fri, 22 Dec 2006 01:11:01 +0100 > From: Lennart Borgman <[EMAIL PROTECTED]> > CC: [EMAIL PROTECTED] 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 > > #include > > > > 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 > #include > #include > #include > #include > > #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()&0x8000) > { > // 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, */ > /*reinterp
Re: National Language Support Functions
Lennart, PLEASE DON'T TAKE THIS DISCUSSION OFF THE LIST!!! > Date: Fri, 22 Dec 2006 12:32:19 +0100 > From: LENNART BORGMAN <[EMAIL PROTECTED]> > Cc: Eli Zaretskii <[EMAIL PROTECTED]> > > It is a bit more complicated than that. All I can say without digging into > the details is that the regional and international settings can be done in > different ways. Please be sure to describe these settings in full detail, on each of the machines where you test this, when you post the results of your testing. > On my pc here it seems like some of those settings makes Emacs believe that I > want Swedish language. However I use English language on the pc. Keyboard, > numbers, currencies, times, time zone and dates are Swedish however. To me, this says that this pc is set up to use the Swedish language, so Emacs seems to do the right thing when it decides to show you the tutorial in Swedish. What are the manifestations of your use of English on this pc? If, as you say, ``keyboard, numbers, currencies, times, time zone and dates are Swedish'', then what aspects of the UI are English? Also, what are the precise regional and international settings on that pc? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug