Carbon: Unicode keyboard layouts does not work properly
Bug report from Christian Lynbech (christian #\@ defun #\. dk),
pertaining to current Carbon Emacsen:
I have been tracking a really annoying problem relating to keyboard
layouts and the meta key.
There appears to be a problem in relation to unicode keymaps, but only
when they deviate from the american layout. In the following I have
used the standard danish (latin) layout and the extended norwegian
(unicode) layout, both part of the default set of layouts. To the best
of my knowledge, the problem does not as such follow the specific
layouts but only whether its latin or unicode (and different from the
US layout).
In the scandinavian keyboard layouts, the characters on top of the
numerical keys deviates slightly wrt. to the american layout. In
particular, on danish (and norwegian) keyboards, the symbol on top of
'8' is a ( while on the US keyboard it is a *.
The symptom I am experiencing is that trying to invoke the emacs
command of `insert-parentheses´ I want to press Meta+Shift+8. When
using the danish latin keyboard layout, I get what I want (ie. M-()
but with a unicode keyboard layout, emacs claims I am pressing M-*
as it would have been on an american keyboard.
In this test I used latest nightly snapshot of Aquamacs without any
.emacs and thus with Alt as meta key but there is no difference when
using the Command key as Meta.
This problem exists in several OSX-based emacs's including Aquamacs
(both 0.9.9d and snapshot), GNU Emacs 22.0.9x (both from porkrind and
aquamacs.org) and Carbon Emacs (Jan 2007 version) but NOT in EmacsApp
(from http://emacs-app.sourceforge.net/) which is based on Emacs 23,
whether or not that is the relevant difference.
Using Peter Maurers Key Codes application, I get the following
trace. The trace contains four key presses, that of Shift+8 and
that of Shift+Alt+8, first for the danish (latin) layout and then
again for the extended norwegian (unicode) layout, and sure enough the
modifier codes are slightly different depending on whether the latin
or unicode layout was used:
Key Codes 1.0 (c) Peter Maurer 2005
Key Down
Characters: (
Unicode:40 / 0x28
Keys: ⇧(
Key Code: 28 / 0x1c
Modifiers: 131074 / 0x20002
Key Down
Characters: {
Unicode:123 / 0x7b
Keys: ⇧⌥(
Key Code: 28 / 0x1c
Modifiers: 655394 / 0xa0022
Key Down
Characters: (
Unicode:40 / 0x28
Keys: ⇧(
Key Code: 28 / 0x1c
Modifiers: 131330 / 0x20102
Key Down
Characters: {
Unicode:123 / 0x7b
Keys: ⇧⌥(
Key Code: 28 / 0x1c
Modifiers: 655650 / 0xa0122
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Some minor stuff in NEWS
In GNU Emacs 22.0.93.1: Comments from reading etc/NEWS: `string-or-null-p' returns non-nil iff OBJECT is a string or nil. `booleanp' returns non-nil iff OBJECT is a t or nil. ^ Remove 'a'. *** rx.el has new corresponding `symbol-end' and `symbol-start' elements. Better to list these in the other order. *** `buffer-undo-list' can allows programmable elements. allows or can allow? emacs crash. When emacs is running in an xterm more key bindings are available. The features of cua also works with the standard emacs bindings for emacs' filename parsing rules. The ignored portion can be made dim, for emacs editing commands, `Cursor keys' and `Shifted Cursor keys' On some systems, when emacs reads the output from a subprocess, the emacs tries to read it. create a stream or datagram server inside emacs. buttons' in emacs buffers. Buttons are much lighter-weight than the For consistency should be Emacs with a capital. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: list-buffers-noselect: `when' should be `and'
These doc changes are ok with me. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: please use ?\u2014 instead of the unicode character in buff-menu.el
Complete disagreement. The coding system is clearly written in the -*- coding -*- tag, so there's no ambiguity, Does this mean that even when the text gets garbled by those browsers it will still be decoded correctly when the resulting file is visited in Emacs? Yes. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: please use ?\u2014 instead of the unicode character in buff-menu.el
Complete disagreement. The coding system is clearly written in the -*- coding -*- tag, so there's no ambiguity, Does this mean that even when the text gets garbled by those browsers it will still be decoded correctly when the resulting file is visited in Emacs? Yes. Stefan On that, I definitely disagree. My experience proves the contrary. I suppose it depends what is meant by text gets garbled by those browsers. What I see is that the characters are themselves changed in the file, and the coding tag therefore has no way of recuperating; it cannot know what characters were intended originally. You have only to download the file from http://cvs.savannah.gnu.org/viewcvs/emacs/emacs/lisp/ to see what I mean. Save it directly to disk and then open it in Emacs (22). I don't know whether this represents a browser problem or a Web site problem, however. I used the most common browser (still), IE6. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: please use ?\u2014 instead of the unicode character in buff-menu.el
From: Drew Adams [EMAIL PROTECTED] Date: Sun, 18 Feb 2007 11:29:57 -0800 Cc: emacs-pretest-bug@gnu.org Does this mean that even when the text gets garbled by those browsers it will still be decoded correctly when the resulting file is visited in Emacs? Yes. Stefan On that, I definitely disagree. My experience proves the contrary. I suppose it depends what is meant by text gets garbled by those browsers. What I see is that the characters are themselves changed in the file, and the coding tag therefore has no way of recuperating; it cannot know what characters were intended originally. You have only to download the file from http://cvs.savannah.gnu.org/viewcvs/emacs/emacs/lisp/ to see what I mean. Save it directly to disk and then open it in Emacs (22). I don't know whether this represents a browser problem or a Web site problem, however. Please tell the details about how you downloaded and saved the file to disk. It is impossible to know what went wrong without these details. I did it twice with two different methods: . Clicked the download link and saved the file to disk. . Clicked the view link; then, after seeing that the Unicode characters are displayed incorrectly, clicked View-Encoding from the menu bar, selected Unicode UTF-8, which fixed the display; then File-Save As, selected Text files and made sure the encoding is set to UTF-8; clicked OK. Both methods gave me a valid UTF-8 encoded file that displayed correctly in Emacs 22. I used the most common browser (still), IE6. Same here. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: please use ?\u2014 instead of the unicode character inbuff-menu.el
Please tell the details about how you downloaded and saved the file to disk. It is impossible to know what went wrong without these details. What went wrong is not the point. However it is that the characters got messed up (Web site, browser, user error, cosmic rays, CIA, Al Qaeda), there is no reason not to use the escape sequence, for portability and better code legibility. I did it twice with two different methods: . Clicked the download link and saved the file to disk. . Clicked the view link; then, after seeing that the Unicode characters are displayed incorrectly, clicked View-Encoding from the menu bar, selected Unicode UTF-8, which fixed the display; then File-Save As, selected Text files and made sure the encoding is set to UTF-8; clicked OK. Both methods gave me a valid UTF-8 encoded file that displayed correctly in Emacs 22. I used the view link, clicking mouse-1 on it, because I wanted to look at the code before saving it. I did not scan the entire file to notice that two of the characters were displayed incorrectly, so I did not change my browser encoding - after all, this is code, which displays as plain text. And how would one know that those two characters were in fact displayed incorrectly? How would you know what they were supposed to be? Did you read all of the code comments, and analyze the code, to come to the conclusion that the browser encoding for those two characters was incorrect? Or did you in fact know just what to look for, because you had read my bug report? That's cheating ;-). Or did you notice the -*- coding: utf-8 -*- in the header, and realize that your current browser encoding didn't correspond to that? You said, however, that you noticed that the (two) Unicode characters were displayed incorrectly - a much harder thing to spot. Some other methods a user might use to try to retrieve the code: - Right-click the download link, and use Save As (as I assume you meant by clicked the 'download' link). Here, you can Save as type All Files. This works. - Right-click the view link, use Save Target As, and Save as type All Files, changing the suffix to el. For some reason, this does nothing, for me - no file is saved. - Click mouse-1 on the download link, and use Save As. This does default to the Unicode encoding, but, at least in my IE6 browser, there is no filter option for All Files at that point, and you must choose Save as type Text File (*.txt) (the other options involving saving as HTML pages). When I open the resulting file in Emacs 22, C-h C shows raw-text-unix, not Unicode, and the buffer is filled with null bytes (^@) - every other byte. C-x RET r utf-8 does not change what I see. The -*- coding never takes effect because each of its characters is preceded by a null character. There are multiple ways a user might try to retrieve this code from that site, and there will be other sites that also offer the code, perhaps in other ways. As I mentioned, I first ran into this problem on the Emacs Wiki (with the same em-dash character, in a library that is derived from buff-menu.el). Simply uploading or downloading the code on the Wiki changes the characters (in the same way, BTW). Here, the downloading user has no choice. If the normal page-edit means of uploading is used, then the characters are messed up in the file on the wiki, so regardless of how you download it, you get garbage. AFAIK, this has nothing to do with the browser. You might not care about the Emacs Wiki, but you might care that such a problem exists there, because other sites might present similar problems. The real point is that there is no good reason *not* to use the escape sequence in this case, and there are good reasons to use it: easier file exchange using email and Internet, and better code legibility. The only reason given so far not to use the escape sequence was code legibility, and I pointed out that the code is in fact less legible without the escape sequence, because the em-dash and hyphen characters are indistinguishable in a fixed font. They both appear as ?-, making it impossible to tell which is which (without a comment). This seems a no-brainer, to me. Further resistance to using the escape sequence in this case seems to me to reflect only unwillingness to see the obvious. If, on the other hand, your concern was the Web site and how to ensure that users download Unicode code correctly, then I share that concern. You might want to include explicit instructions for how to download, and explicit mention that view of code that includes Unicode characters might require that you change your browser encoding to Unicode. Or something like that. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: please use ?\u2014 instead of the unicode character inbuff-menu.el
Drew Adams wrote: As I mentioned, I first ran into this problem on the Emacs Wiki (with the same em-dash character, in a library that is derived from buff-menu.el). Simply uploading or downloading the code on the Wiki changes the characters (in the same way, BTW). Here, the downloading user has no choice. If the normal page-edit means of uploading is used, then the characters are messed up in the file on the wiki, so regardless of how you download it, you get garbage. AFAIK, this has nothing to do with the browser. You might not care about the Emacs Wiki, but you might care that such a problem exists there, because other sites might present similar problems. I wonder if this has something to do with the mime codes? I do not know anything about it, but could it be that the web server changes something in the output? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: please use ?\u2014 instead of the unicode character inbuff-menu.el
From: Drew Adams [EMAIL PROTECTED] Cc: emacs-pretest-bug@gnu.org Date: Sun, 18 Feb 2007 14:15:14 -0800 Please tell the details about how you downloaded and saved the file to disk. It is impossible to know what went wrong without these details. What went wrong is not the point. [] Well, you did say I don't know whether this represents a browser problem or a Web site problem, however. All I did was try to help you find out what went wrong. No good deed goes unpunished, sigh... ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: please use ?\u2014 instead of the unicode character inbuff-menu.el
Date: Sun, 18 Feb 2007 23:32:01 +0100 From: Lennart Borgman (gmail) [EMAIL PROTECTED] CC: Eli Zaretskii [EMAIL PROTECTED], emacs-pretest-bug@gnu.org I wonder if this has something to do with the mime codes? I do not know anything about it, but could it be that the web server changes something in the output? I think the problem is simply that IE, like Emacs, needs to be told the encoding explicitly, when its defaults are wrong. There's no magic wand here. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: please use ?\u2014 instead of the unicode character inbuff-menu.el
As I mentioned, I first ran into this problem on the Emacs Wiki (with the same em-dash character, in a library that is derived from buff-menu.el). Simply uploading or downloading the code on the Wiki changes the characters (in the same way, BTW). Here, the downloading user has no choice. If the normal page-edit means of uploading is used, then the characters are messed up in the file on the wiki, so regardless of how you download it, you get garbage. AFAIK, this has nothing to do with the browser. I wonder if this has something to do with the mime codes? I do not know anything about it, but could it be that the web server changes something in the output? Dunno. Perhaps it has to do with the scripts used on the Wiki. The problem here is more general than Unicode, in fact. For example, it also strips out control characters (e.g. ^L) inserted in the code. In one library, for instance, I use escape sequences instead of embedded ^G and ^J characters. However, the loss of ^L page separators is regrettable. You can upload a file to the wiki using the alternative method, instead of editing a wiki page, and in that case there is no problem. But in that case there is also no syntactic highlighting of the code on the page. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: please use ?\u2014 instead of the unicode character inbuff-menu.el
Eli Zaretskii wrote: Date: Sun, 18 Feb 2007 23:32:01 +0100 From: Lennart Borgman (gmail) [EMAIL PROTECTED] CC: Eli Zaretskii [EMAIL PROTECTED], emacs-pretest-bug@gnu.org I wonder if this has something to do with the mime codes? I do not know anything about it, but could it be that the web server changes something in the output? I think the problem is simply that IE, like Emacs, needs to be told the encoding explicitly, when its defaults are wrong. There's no magic wand here. Maybe, I just do not understand why IE6 just does not save the bytestream it recieves. Or is that not possible here for some reason? Could it be that IE6 cashes the page and then misread the cache? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: please use ?\u2014 instead of the unicode character inbuff-menu.el
Drew Adams wrote: You can upload a file to the wiki using the alternative method, instead of editing a wiki page, and in that case there is no problem. But in that case there is also no syntactic highlighting of the code on the page. It seems to me you have to know a lot here to be able to understand what is going on. For example the EmacsWiki pages for elisp modules does not tell anything about encoding. What does that mean in this case? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: please use ?\u2014 instead of the unicode character inbuff-menu.el
Please tell the details about how you downloaded and saved the file to disk. It is impossible to know what went wrong without these details. What went wrong is not the point. [] Well, you did say I don't know whether this represents a browser problem or a Web site problem, however. All I did was try to help you find out what went wrong. No good deed goes unpunished, sigh... It was not clear to me that that was all you were doing. It seemed to me that you were also arguing that the real problem was browser, Web site, or user error, not the file contents, and that therefore the file need not be fixed. This was the main point of my last message: What went wrong in downloading the file is not the real point of my bug report. I would like the file itself to be fixed, so that no such problem can possibly arise, regardless of how the file might be downloaded. Yes, a possible problem with the Web site is a secondary concern. It was not obvious to me that you were not also arguing for not fixing the file. So, I argued again for fixing it, and I argued that Web site or user error is not a good reason not to fix the bug. It did occur to me that you might *only* be trying to help find out what went wrong, which is why I also wrote If, on the other hand, your concern was the site and how to ensure that users download Unicode code correctly, then I share that concern... I tried to understand your intent and your message, but I was not sure what your point was. My main concern is the file's Unicode characters. Arguments against fixing the file are the first thing I wanted to rebut. And my interpretation #1 of your response was that you were essentially saying that the real problem is one of correctly downloading the file: just download correctly; no need to fix the file. Not knowing quite what you meant, I tried to reply to both of my interpretations of your good deed, with priority to what I think is most important: fixing the file. If you had made it clear that you supported fixing the file and you were only offering help to find out what went wrong with the download, then I wouldn't have said anything about interpretation #1. Sorry if I misunderstood you. I was only trying to separate the bug report from a possible Web-page download problem. No good deed goes unpunished, it seems... ;-) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: please use ?\u2014 instead of the unicode character inbuff-menu.el
I wonder if this has something to do with the mime codes? I do not know anything about it, but could it be that the web server changes something in the output? I think the problem is simply that IE, like Emacs, needs to be told the encoding explicitly, when its defaults are wrong. There's no magic wand here. I didn't think so, but I just made a test on the wiki, and I think you are probably right. I was able to insert Unicode characters in a new lisp-file page, and they were retained properly after saving - so what I said before is apparently wrong. I don't know if there was a change to the wiki recently or if this was always the case. I do know that, with the same browser and the same browser encoding, I ran into a problem before, but perhaps it was something I did. FWIW, I just noticed that my browser is set to Unicode for the encoding, and it was when I picked up the file with the broken characters. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: please use ?\u2014 instead of the unicode character inbuff-menu.el
On 2/18/07, Drew Adams [EMAIL PROTECTED] wrote: [...] so I did not change my browser encoding - after all, this is code, which displays as plain text. That assumption is just wrong, and more and more with each passing day. elisp is not the only language where you can have source that contains non-ASCII chars (it is perfectly legal in Ada, for example, and Perl). Yes, I know you're arguing that buff-menu.el contains just one non-ASCII char and it would be friendlier to use an escape (It's me who added the comment line just above the one which is causing you so much grief.) Perhaps you're right. But you said yourself your fix wouldn't work for packages with lots of Unicode chars. Where do you intend to put the line? At ten chars? A thousand? And how do you propose to inform the user, used to code which displays as plain text, that suddenly this other code isn't downloadable with broken tools anymore? I don't care about buff-menu.el, and won't argue for or against changing one character; but the fix for the problem you're struggling with is educating the users, and pointing them to non-broken tools. Obviously, we can't (nor should) force anyone to change their ways; but I don't see why should we make extraordinary efforts to suit them, either. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Customization: Toggle buttons vanish when clicked
Back out my patch, and document that you need text before %v in :format in editable-field instead. That would be my suggestion. -- Per On 2/18/07, Chris Moore [EMAIL PROTECTED] wrote: No. I've seen absolutely no response to either of my two reports other than your 'has this been fixed?' question. I was wondering if maybe the problem doesn't happen for anyone else, so I tried installing Lennart's Windows build on a separate PC I have access to, and exactly the same happens there. I've CC'ed this to Per (whose change introduced the bug) in the hope that he's able to fix it. Chris. On 2/18/07, Richard Stallman [EMAIL PROTECTED] wrote: Has this been fixed? From: Chris Moore [EMAIL PROTECTED] To: emacs-pretest-bug@gnu.org Date: Mon, 12 Feb 2007 19:43:29 +0100 Subject: Customization: Toggle buttons vanish when clicked X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.0.4 Doing the following causes the 'Toggle' button to vanish: $ emacs -Q M-x customize-variable RET case-fold-search RET C-s Togg RET RET Backing out this change fixes the problem: 2007-02-04 Per Abrahamsen [EMAIL PROTECTED] * wid-edit.el (widget-default-create): Insert new text at the :from marker _after_ the marker, not before it. Chris. In GNU Emacs 22.0.93.37 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-02-12 on trpaslik X server distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--with-gtk' '--prefix' '/usr/local' '--with-xpm' '--with-jpeg' '--with-png' '--with-gif'' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: please use ?\u2014 instead of the unicode character inbuff-menu.el
On 2/19/07, Drew Adams [EMAIL PROTECTED] wrote: I don't intend to establish a line. Judgement is needed, perhaps case by case. That still doesn't help the user who doesn't know what your decision was. What I said, in an earlier mail, was this: I know. I've said that I know what you were arguing for. Good question, and one that I raised in response to Eli's mail. Excuse me for not reading the threads in the order that would be more convenient to you ;-) Maybe we should say explicitly that all code should be downloaded using a Unicode encoding - I don't know. I'm not sure *we* should do it, in the sense that people who downloads code from their browser is bound to learn sooner or later that it is a bad idea to ignore encodings. We will have to live with it, until the world (including Emacs ;-)) is Unicode through and through. Not doing anything is a way to live wit it. Making it easier for the user to continue to ignore the issue is not helpful, long term. Our best recourse, at least in this transitional period, is to be aware of the potential gotchas and use our best judgement to help users avoid problems. That's all; I don't have a better suggestion than that. Maybe someone else does. I agree. I just don't think the problem of people downloading a wrong copy of buff-menu.el is really pressing. I'd say most people gets Emacs in full, either from a source tarball, a binary package or CVS. No, the fix for the problem that I reported is to use an escape sequence in buff-menu.el. I was referring, obviously, to the general problem, not the specific buff-menu.el issue. You say that you weren't talking about the general problem, so let's leave it at that. This sideline discussion (this problem that you are apparently struggling with, and that you think I am struggling with) Oh, I assure you that I'm not struggling with any Emacs problem right now, other than restlessly waiting for Emacs 22 to be released. We can at least do what we can to prevent that problem from arising in no-brainer cases such as buff-menu.el. No comment, as I already said I don't mind this specific case. It's just common sense. And replacing two em-dash characters with \u2014 is hardly making extraordinary efforts. No. Taking the time to discuss a change that should, in an ideal world, be unnecessary and even ill-advised, and also the time do think where to draw the line, is an extraordinary (beyond what is ordinary or usual, not highly unusual or exceptional or remarkable) effort. It does, however, sometimes seem to take extraordinary efforts to get the slightest suggestion across to change something, even something trivial, in the Emacs code. Your (everybody's) trivial is other people's bad idea, sometimes. As with all bug reports, it's up to you whether you want to consider this a bug and, if so, whether you want to fix it, and how. I bow to others in that collective you. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Carbon: Unicode keyboard layouts does not work properly
On Sun, 18 Feb 2007 13:09:42 +, David Reitter [EMAIL PROTECTED]
said:
The symptom I am experiencing is that trying to invoke the emacs
command of `insert-parentheses´ I want to press Meta+Shift+8. When
using the danish latin keyboard layout, I get what I want
(ie. M-() but with a unicode keyboard layout, emacs claims I am
pressing M-* as it would have been on an american keyboard.
Thanks for the report. I could reproduce it.
Actually, I'm not sure why the current code does not work. But the
Keyboard Layout Services API, which is available on Mac OS X 10.2 and
later, seems to solve the problem. Could you try the following patch?
YAMAMOTO Mitsuharu
[EMAIL PROTECTED]
Index: src/macterm.c
===
RCS file: /cvsroot/emacs/emacs/src/macterm.c,v
retrieving revision 1.204
diff -c -p -r1.204 macterm.c
*** src/macterm.c 13 Feb 2007 08:28:39 - 1.204
--- src/macterm.c 19 Feb 2007 01:06:40 -
*** XTread_socket (sd, expected, hold_quit)
*** 11165,11170
--- 11165,11180
/* translate the keycode back to determine the
original key */
#ifdef MAC_OSX
+ UCKeyboardLayout *uchr_ptr = NULL;
+ #if MAC_OS_X_VERSION_MAX_ALLOWED = 1020
+ OSStatus err;
+ KeyboardLayoutRef layout;
+
+ err = KLGetCurrentKeyboardLayout (layout);
+ if (err == noErr)
+ KLGetKeyboardLayoutProperty (layout, kKLuchrData,
+ (const void **) uchr_ptr);
+ #else
static SInt16 last_key_layout_id = 0;
static Handle uchr_handle = (Handle)-1;
SInt16 current_key_layout_id =
*** XTread_socket (sd, expected, hold_quit)
*** 11176,11183
uchr_handle = GetResource ('uchr', current_key_layout_id);
last_key_layout_id = current_key_layout_id;
}
-
if (uchr_handle)
{
OSStatus status;
UInt16 key_action = er.what - keyDown;
--- 11186,11196
uchr_handle = GetResource ('uchr', current_key_layout_id);
last_key_layout_id = current_key_layout_id;
}
if (uchr_handle)
+ uchr_ptr = (UCKeyboardLayout *)*uchr_handle;
+ #endif
+
+ if (uchr_ptr)
{
OSStatus status;
UInt16 key_action = er.what - keyDown;
*** XTread_socket (sd, expected, hold_quit)
*** 11188,11194
UniChar code;
UniCharCount actual_length;
! status = UCKeyTranslate ((UCKeyboardLayout *)*uchr_handle,
keycode, key_action,
modifier_key_state,
keyboard_type,
--- 11201,11207
UniChar code;
UniCharCount actual_length;
! status = UCKeyTranslate (uchr_ptr,
keycode, key_action,
modifier_key_state,
keyboard_type,
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: please use ?\u2014 instead of the unicode character inbuff-menu.el
Date: Sun, 18 Feb 2007 23:48:29 +0100 From: Lennart Borgman (gmail) [EMAIL PROTECTED] CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org Eli Zaretskii wrote: Date: Sun, 18 Feb 2007 23:32:01 +0100 From: Lennart Borgman (gmail) [EMAIL PROTECTED] CC: Eli Zaretskii [EMAIL PROTECTED], emacs-pretest-bug@gnu.org I wonder if this has something to do with the mime codes? I do not know anything about it, but could it be that the web server changes something in the output? I think the problem is simply that IE, like Emacs, needs to be told the encoding explicitly, when its defaults are wrong. There's no magic wand here. Maybe, I just do not understand why IE6 just does not save the bytestream it recieves. For the same reason Emacs doesn't do that with non-ASCII text: it doesn't treat it as a byte stream, it treats it as an encoded text. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: info-lookup slow
Eli Zaretskii schrieb: Date: Sun, 11 Feb 2007 16:40:21 +0100 From: Andreas Roehler [EMAIL PROTECTED] CC: emacs-pretest-bug@gnu.org, Stefan Monnier [EMAIL PROTECTED], Richard Stallman [EMAIL PROTECTED] Ok now with CVS-Emacs, back to ten seconds, thanks. However, looking up symbol `defun' for example after prompt took still 38 seconds. As this command isn't called often, I can live with - just to mention it. Thanks for following up. I think the change below should fix this remaining problem as well: 2007-02-17 Eli Zaretskii [EMAIL PROTECTED] * info-look.el (info-lookup): Bind Info-fontify-maximum-menu-size to nil to speed up lookup of the symbol in index nodes. Index: lisp/info-look.el === RCS file: /cvsroot/emacs/emacs/lisp/info-look.el,v retrieving revision 1.55 diff -u -r1.55 info-look.el --- lisp/info-look.el 10 Feb 2007 11:12:42 - 1.55 +++ lisp/info-look.el 17 Feb 2007 11:59:07 - @@ -353,8 +353,11 @@ suffix (nth 3 (car doc-spec))) (when (condition-case error-data (progn - (Info-goto-node node) - (setq doc-found t)) + ;; Don't need Index menu fontifications here, and + ;; they slow down the lookup. + (let (Info-fontify-maximum-menu-size) + (Info-goto-node node) + (setq doc-found t))) (error (message Cannot access Info node %s node) (sit-for 1) It's fine now. Just a few seconds. Thanks. __ Andreas Roehler GNU Emacs 22.0.93.4 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2007-02-18 on kiste ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
