Re: memory leak in xpm_load
On Wed, 6 Jun 2007 11:41:24 +0200, Juanma Barranquero [EMAIL PROTECTED] said: On 6/6/07, YAMAMOTO Mitsuharu [EMAIL PROTECTED] wrote: In xpm_load (if HAVE_XPM and ALLOC_XPM_COLORS), xpm_init_color_cache is called twice without an intervening xpm_free_color_cache call, and that causes a memory leak ~4KB per XPM image creation. Try removing the second one; I think it's a leftover from a patch by Chong. I don't think I fully understand the code, but attr-numsymbols in xpm_init_color_cache becomes always 0 if the second call is removed. Is that right? YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
memory leak in xpm_load
In xpm_load (if HAVE_XPM and ALLOC_XPM_COLORS), xpm_init_color_cache is called twice without an intervening xpm_free_color_cache call, and that causes a memory leak ~4KB per XPM image creation. YAMAMOTO Mitsuharu [EMAIL PROTECTED] In GNU Emacs 22.1.50.1 (sparc-sun-solaris2.8, X toolkit, Xaw3d scroll bars) of 2007-06-06 on church Windowing system distributor `ATT Laboratories Cambridge', version 11.0.3332 configured using `configure '--x-libraries=/usr/local/lib' 'CFLAGS=-g -O2 -mv8 -DSYNC_INPUT'' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash: XSetWMIconName, x_set_name_internal, prepare_menu_bars
On Mon, 04 Jun 2007 09:38:14 +0900, Kenichi Handa [EMAIL PROTECTED] said: Such GCPROs are not necessary because x_encode_text is called with the third arg SELECTIONP == 0. Actually, there's no SELECTIONP != 0 case in the current Emacs code. I remember that x_encode_text had been used to encode X selection data, but now it is not in Emacs 22. But, in emacs-unicode-2, x_encode_text uses encode_coding_object, and that function does call Lisp for pre-write-conversion. That seems to mean there's another string data relocation problem that `text.value' might get corrupted by the subsequent x_encode_text call for `icon.value' in emacs-unicode-2 even on non-GTK+ builds. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash: XSetWMIconName, x_set_name_internal, prepare_menu_bars
On Fri, 01 Jun 2007 10:51:12 -0400, Richard Stallman [EMAIL PROTECTED] said: After looking at it, I realized there was no need to call x_encode_text in the GTK case. So I separated the two cases completely, which should improve things. I'm not so familiar with GTK+, but is the call to XSetWMIconName unnecessary in the GTK+ case? Previously, it was called in both cases and that was the reason for x_encode_text in the GTK+ case. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash: XSetWMIconName, x_set_name_internal, prepare_menu_bars
On Fri, 01 Jun 2007 18:42:57 -0400, Chong Yidong [EMAIL PROTECTED] said: I looked at the GTK+ sources. Apparently, if we don't set WM_ICON_NAME ourselves, gtk_window_set_icon_name sets WM_ICON_NAME for us. So I think we are perfectly safe. But now we can't set the icon title separately from the frame title using the `icon-name' frame parameter on GTK+ builds. `icon-name' The name to use in the icon for this frame, when and if the icon appears. If this is `nil', the frame's title is used. Even with non-GTK+ builds, setting this parameter might not affect the icon title for some window managers. But at least, CDE on Solaris respects this. Maybe we can use gtk_window_set_icon_name for this purpose, but it is available only on GTK+ 2.6 and later, so some check will be necessary and it is definitely after-the-release matter. So I propose undoing the latest change for x_set_name_internal for now. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash: XSetWMIconName, x_set_name_internal, prepare_menu_bars
On Fri, 01 Jun 2007 00:35:33 +0200, [EMAIL PROTECTED] (Kim F. Storm) said: I had a crash yesterday with the emacs 22 branch (not fully up-to-date, but close): GNU Emacs 22.0.990.1 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-05-23 on kfs-lx It is built on an up-to-date Debian Stable system. Emacs had probably been running for approx. 20 hours, and the last command I executed which triggered the crash was C-x 5 b (that's ido-switch-buffer-other-frame), selected a buffer from the list, and hit RET. I think it crashed while creating the new frame; I don't recall seeing the frame appear, but I'm not absolutely sure. I think this is due to string data relocation caused by ENCODE_UTF_8 in x_set_name_internal (GTK+ only). YAMAMOTO Mitsuharu [EMAIL PROTECTED] Index: src/xfns.c === RCS file: /sources/emacs/emacs/src/xfns.c,v retrieving revision 1.681 diff -c -p -r1.681 xfns.c *** src/xfns.c 24 Mar 2007 15:40:38 - 1.681 --- src/xfns.c 1 Jun 2007 01:00:51 - *** x_set_name_internal (f, name) *** 1605,1610 --- 1605,1615 int bytes, stringp; int do_free_icon_value = 0, do_free_text_value = 0; Lisp_Object coding_system; + #ifdef USE_GTK + /* As ENCODE_UTF_8 may cause GC and relocation of string data, + we use it before x_encode_text that may return string data. */ + Lisp_Object encoded_name = ENCODE_UTF_8 (name); + #endif coding_system = Qcompound_text; /* Note: Encoding strategy *** x_set_name_internal (f, name) *** 1645,1651 #ifdef USE_GTK gtk_window_set_title (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)), ! (char *) SDATA (ENCODE_UTF_8 (name))); #else /* not USE_GTK */ XSetWMName (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f), text); #endif /* not USE_GTK */ --- 1650,1656 #ifdef USE_GTK gtk_window_set_title (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)), ! (char *) SDATA (encoded_name)); #else /* not USE_GTK */ XSetWMName (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f), text); #endif /* not USE_GTK */ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash: XSetWMIconName, x_set_name_internal, prepare_menu_bars
On Fri, 01 Jun 2007 10:05:41 +0900, YAMAMOTO Mitsuharu [EMAIL PROTECTED] said: I think this is due to string data relocation caused by ENCODE_UTF_8 in x_set_name_internal (GTK+ only). GCPRO was missing in the previous patch. Below is a revised one. YAMAMOTO Mitsuharu [EMAIL PROTECTED] Index: src/xfns.c === RCS file: /sources/emacs/emacs/src/xfns.c,v retrieving revision 1.681 diff -c -p -r1.681 xfns.c *** src/xfns.c 24 Mar 2007 15:40:38 - 1.681 --- src/xfns.c 1 Jun 2007 03:24:43 - *** x_set_name_internal (f, name) *** 1605,1610 --- 1605,1620 int bytes, stringp; int do_free_icon_value = 0, do_free_text_value = 0; Lisp_Object coding_system; + #ifdef USE_GTK + Lisp_Object encoded_name; + struct gcpro gcpro1; + + /* As ENCODE_UTF_8 may cause GC and relocation of string data, + we use it before x_encode_text that may return string data. */ + GCPRO1 (name); + encoded_name = ENCODE_UTF_8 (name); + UNGCPRO; + #endif coding_system = Qcompound_text; /* Note: Encoding strategy *** x_set_name_internal (f, name) *** 1645,1651 #ifdef USE_GTK gtk_window_set_title (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)), ! (char *) SDATA (ENCODE_UTF_8 (name))); #else /* not USE_GTK */ XSetWMName (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f), text); #endif /* not USE_GTK */ --- 1655,1661 #ifdef USE_GTK gtk_window_set_title (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)), ! (char *) SDATA (encoded_name)); #else /* not USE_GTK */ XSetWMName (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f), text); #endif /* not USE_GTK */ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
On Mon, 28 May 2007 10:58:00 +0200, martin rudalics [EMAIL PROTECTED] said: Reports from Windows users still wanted. Works here, thanks. Sorry, no. With a newline after the html/html and moving down and back that line I get sgml-point-entered: Lisp nesting exceeds `max-lisp-eval-depth' I couldn't reproduce it on Mac OS X. It only shows an error like forward-list: Scan error: Containing expression ends prematurely If I define `sgml-point-entered' as (defun sgml-point-entered (x y) ;; Show preceding or following hidden tag, depending of cursor direction. (let ((inhibit-point-motion-hooks t) (tag-string (save-excursion ;; Strip properties, otherwise, the text is invisible. (buffer-substring-no-properties (point) (if (or (and ( x y) (not (eq (following-char) ?))) (and ( x y) (eq (preceding-char) ?))) (condition-case nil (backward-list) (error (point))) (condition-case nil (forward-list) (error (point (unless (string-equal tag-string ) (message Invisible tag: %s tag-string it stalls as before with 100% CPU consumption. I could reproduce this, but shouldn't the above `let' be `let*'? YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
On Sun, 27 May 2007 00:45:55 +0200, martin rudalics [EMAIL PROTECTED] said: (2) A bug in redisplay. Somewhere Qinhibit_point_motion_hooks doesn't get bound to Qt but so far I was not able to find out where. There's evidence that the bug shows up when `column-number-mode' is enabled, `current-column' is called and triggers sgml's point-entered hook. Maybe it's got something to do with sgml's invisibility properties. Kim would find this in five minutes, but where are thou ... Unless someone who is familiar with this matter gives a better one, I'd propose the following minimal and conservative change to avoid regression at this stage. YAMAMOTO Mitsuharu [EMAIL PROTECTED] Index: src/indent.c === RCS file: /cvsroot/emacs/emacs/src/indent.c,v retrieving revision 1.192 diff -c -p -r1.192 indent.c *** src/indent.c8 Apr 2007 23:59:19 - 1.192 --- src/indent.c27 May 2007 06:37:11 - *** current_column_1 () *** 522,527 --- 522,531 scan_newline (PT, PT_BYTE, BEGV, BEGV_BYTE, -1, 1); current_column_bol_cache = PT; scan = PT, scan_byte = PT_BYTE; + /* Restore point to the original value. */ + TEMP_SET_PT_BOTH (opoint, opoint_byte); + /* This might be unnecessary, but we leave it in order to avoid + regression. */ SET_PT_BOTH (opoint, opoint_byte); next_boundary = scan; ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
On Sun, 27 May 2007 11:12:35 +0200, martin rudalics [EMAIL PROTECTED] said: Unless someone who is familiar with this matter gives a better one, I'd propose the following minimal and conservative change to avoid regression at this stage. It's too minimal. The following SET_PT_BOTH (opoint, opoint_byte); still spoils everything on Windows. Commenting out that line works, though. Hmm, I couldn't test on Windows, and my previous patch worked on Mac OS X (both X11 and Carbon) and Solaris for the original problem. I continue to have no idea how current_column gets called with Qinhibit_point_motion_hooks not bound to Qt here ... Maybe you can find such traces by setting a breakpoint to current_column with the condition `Vinhibit_point_motion_hooks == Qnil'. I found the following cases: pos_visible_p - display_mode_line echo_area_display - redisplay_mode_lines - display_mode_lines - display_mode_line YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
On Sun, 27 May 2007 14:09:07 +0200, martin rudalics [EMAIL PROTECTED]
said:
Hmm, I couldn't test on Windows, and my previous patch worked on
Mac OS X (both X11 and Carbon) and Solaris for the original
problem.
Hence the original problem is present on these platforms?
Yes. And there was a report that it could be reproduced on GNU/Linux.
I guess Chong was using another html-mode.
I continue to have no idea how current_column gets called with
Qinhibit_point_motion_hooks not bound to Qt here ...
Maybe you can find such traces by setting a breakpoint to
current_column with the condition `Vinhibit_point_motion_hooks ==
Qnil'. I found the following cases:
pos_visible_p - display_mode_line echo_area_display -
redisplay_mode_lines - display_mode_lines - display_mode_line
Thanks, I'm aware of these. I don't understand why pos_visible_p
should be called by redisplay. For the second one I earlier tried
to specbind Qinhibit_point_motion_hooks around it - to no avail. I
have to retry.
Maybe you need to use specbind for the `current_column' call in
redisplay_internal instead.
*** src/xdisp.c.~1.1149.2.2.~ Fri May 25 11:00:00 2007
--- src/xdisp.c Sun May 27 22:48:48 2007
*** redisplay_internal (preserve_echo_area)
*** 10888,10893
--- 10888,10894
Fcons (make_number (redisplaying_p), selected_frame));
++redisplaying_p;
specbind (Qinhibit_free_realized_faces, Qnil);
+ specbind (Qinhibit_point_motion_hooks, Qt);
{
Lisp_Object tail, frame;
This patch works on Mac OS X for the original problem (without my
previous patch). Adding specbind and unbind_to around the
`current_column' in redisplay_internal also works.
YAMAMOTO Mitsuharu
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
On Sun, 27 May 2007 19:21:28 -0400, Richard Stallman [EMAIL PROTECTED] said: Where is the actual call to `current_column' for which you specifically want to bind this? Could you bind Qinhibit_point_motion_hooks for just that? I meant the only direct call to `current_column' from redisplay_internal: /* If %c is in the mode line, update it if needed. */ if (!NILP (w-column_number_displayed) /* This alternative quickly identifies a common case where no change is needed. */ !(PT == XFASTINT (w-last_point) XFASTINT (w-last_modified) = MODIFF XFASTINT (w-last_overlay_modified) = OVERLAY_MODIFF) (XFASTINT (w-column_number_displayed) != (int) current_column ())) /* iftc */ w-update_mode_line = Qt; and as I said, binding Qinhibit_point_motion_hooks just around this part as the following patch also works for me on Mac OS X. Could someone check if this works on Windows for the original problem? Index: src/xdisp.c === RCS file: /cvsroot/emacs/emacs/src/xdisp.c,v retrieving revision 1.1149.2.2 diff -c -p -r1.1149.2.2 xdisp.c *** src/xdisp.c 24 May 2007 23:21:32 - 1.1149.2.2 --- src/xdisp.c 28 May 2007 00:33:00 - *** redisplay_internal (preserve_echo_area) *** 10836,10842 int must_finish = 0; struct text_pos tlbufpos, tlendpos; int number_of_visible_frames; ! int count; struct frame *sf; int polling_stopped_here = 0; --- 10836,10842 int must_finish = 0; struct text_pos tlbufpos, tlendpos; int number_of_visible_frames; ! int count, count1; struct frame *sf; int polling_stopped_here = 0; *** redisplay_internal (preserve_echo_area) *** 10974,10979 --- 10974,10983 update_mode_lines++; } + /* Avoid invocation of point motion hooks by `current_column' below. */ + count1 = SPECPDL_INDEX (); + specbind (Qinhibit_point_motion_hooks, Qt); + /* If %c is in the mode line, update it if needed. */ if (!NILP (w-column_number_displayed) /* This alternative quickly identifies a common case *** redisplay_internal (preserve_echo_area) *** 10985,10990 --- 10989,10996 != (int) current_column ())) /* iftc */ w-update_mode_line = Qt; + unbind_to (count1, Qnil); + FRAME_SCROLL_BOTTOM_VPOS (XFRAME (w-frame)) = -1; /* The variable buffer_shared is set in redisplay_window and Or what about binding it in `current_column_1'? Maybe that is the right thing to do. Sorry, I'm afraid I'm not familiar enough with this matter. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
On Sun, 27 May 2007 22:32:28 -0400, Chong Yidong [EMAIL PROTECTED] said: Could someone check if this works on Windows for the original problem? It fixes the bug as seen on GNU/Linux (i.e., with `debug-on-error' on, I no longer see a `forward-list' error with original bug recipe; I never observed the other operations are blocked part of the bug report on this platform.) Let's get this into the branch. Done. Reports from Windows users still wanted. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Carbon: resize event from accessibility API
On Mon, 21 May 2007 12:03:12 +0100, David Reitter [EMAIL PROTECTED] said: Begin forwarded message: From: Pedro Pinto [EMAIL PROTECTED] Date: 18 May 2007 22:11:38 BDT To: [EMAIL PROTECTED] Subject: [Aquamacs-bugs] (no subject) Aquamacs seems to react poorly when told to resize one of its windows through the accessibility API. To reproduce this bug run the UIElementInspector app (http://developer.apple.com/samplecode/ UIElementInspector/index.html) using it to set change AXSize property of the Aquamacs window. The window bill resize, but the scrollbars and general layout will not be redrawn to fit the new size. Does this change work? YAMAMOTO Mitsuharu [EMAIL PROTECTED] *** src/macterm.c.~1.214.2.2.~ Sat May 19 14:08:55 2007 --- src/macterm.c Mon May 21 21:06:22 2007 *** mac_handle_window_event (next_handler, e *** 9893,9898 --- 9893,9899 width = bounds.right - bounds.left; height = bounds.bottom - bounds.top; mac_handle_size_change (f, width, height); + mac_wakeup_from_rne (); } } ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Carbon: Option-as-Meta Sometimes Inputs Accented Characters
On Sat, 12 May 2007 07:51:28 +0100, David Reitter [EMAIL PROTECTED]
said:
On 12 May 2007, at 05:58, Tom Tobin wrote:
I'm using the Aquamacs nightlies (Intel), and have Option set to
act as Meta (no accented characters). When I use and hold down a
meta-key combo (say, M-v to scroll the page), Aquamacs will often
let the equivalent accented character slip through (e.g., √ for
M-v). So far, I've only been able to reproduce this behavior if
the command in question involves scrolling; the quickest way to
reproduce it is to scroll up and down quickly in alternation,
holding down each respective key for a few seconds each time.
Can anyone reproduce this? This is a build from the 22 branch, with
`mac-option-modifier' set to `meta'.
What I can reproduce is holding down M-n: when input just once, it
just brings up an echo area message saying that it's not bound. But
when held down (which causes the input to repeat), it'll input the
tilde dead key (˜) just like when the option modifier is passed to
the system. NB Switching off `mac-input-method-mode' (a patch in
Aquamacs) doesn't change anything, and the problem shows up in a
(Carbon) build straight from the GNU Emacs CVS as well. But I can't
reproduce the M-v problem.
I could reproduce the Option-n case and I think the following patch
will fix it. But the patch fixes a problem with dead-key processing,
and I have no idea about the Option-v case. Is it possible for the OP
to try to reproduce it with a Carbon build straight from GNU Emacs
CVS (with setting mac-option-modifier to meta)?
YAMAMOTO Mitsuharu
[EMAIL PROTECTED]
*** emacs/src/macterm.c.~1.214.~Fri Apr 13 17:14:46 2007
--- emacs/src/macterm.c Sat May 12 19:23:49 2007
*** static Boolean mac_convert_event_ref (Ev
*** 9201,9206
--- 9201,9207
switch (GetEventKind (eventRef))
{
case kEventRawKeyDown:
+ case kEventRawKeyRepeat:
{
unsigned char char_codes;
UInt32 key_code;
*** static Boolean mac_convert_event_ref (Ev
*** 9214,9220
NULL, key_code);
if (err == noErr)
{
! eventRec-what = keyDown;
eventRec-message = char_codes | ((key_code 0xff) 8);
result = 1;
}
--- 9215,9224
NULL, key_code);
if (err == noErr)
{
! if (GetEventKind (eventRef) == kEventRawKeyDown)
! eventRec-what = keyDown;
! else
! eventRec-what = autoKey;
eventRec-message = char_codes | ((key_code 0xff) 8);
result = 1;
}
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Carbon: Option-as-Meta Sometimes Inputs Accented Characters
On Sat, 12 May 2007 13:46:50 -0500, Tom Tobin [EMAIL PROTECTED] said: I could reproduce the Option-n case and I think the following patch will fix it. But the patch fixes a problem with dead-key processing, and I have no idea about the Option-v case. Is it possible for the OP to try to reproduce it with a Carbon build straight from GNU Emacs CVS (with setting mac-option-modifier to meta)? Yes, I can reproduce it with a Carbon GNU Emacs build. The bug happens whenever any two Meta keys, each bound to scroll commands, are pressed and held down in alternation (e.g., bind M-n to scroll-up, and then alternate in a buffer spanning several screen-lengths between holding down M-n for a second or two, then M-v for a second or two, then M-n again, etc.; you will see the √ character inserted into the buffer for M-v, and the dead-key symbol inserted for M-n.). The issue is definitely not specific to dead keys. Still I can't reproduce it on a Carbon build with my previous patch, which is only for the dead-key cases. Could you show a concrete procedure starting from .../Emacs.app/Contents/MacOS/Emacs -Q? What I tried was: 1) /Applications/Emacs.app/Contents/MacOS/Emacs -Q 2) Evaluate (setq mac-option-modifier 'meta) and (global-set-key \M-n 'scroll-up) in *scratch*. 3) C-h n to show Emacs News. 4) Hold down Option-n for a second or two, then Option-v for a second or two, then Option-n again, etc. I'm using Mac OS X 10.4.9, PowerBook G4, US keyboard layout. Also, to make sure, please try some case that does not involve any dead-keys. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Carbon Emacs won't start when installed in certain paths
On Wed, 09 May 2007 17:36:37 +0900, YAMAMOTO Mitsuharu [EMAIL
PROTECTED] said:
Though the non-ASCII unibyte `default-directory' case seems to be
sufficient for the originally reported problem, we should also handle
the following cases in order to make Fexpand_file_name consistent and
exhaustive with respect to non-ASCII unibyte file names:
1. Case that ~ or ~user is expanded to a non-ASCII file name:
This case is similar to the non-ASCII unibyte `default-directory'
case.
2. Case that the argument `name' is in non-ASCII unibyte and
`default-directory' is in multibyte:
This case may return a wrong result either with or without my
previous patch.
I tried handling these cases (with DECODE_FILE instead of
string_to_multibyte). What's pointed to by `newdir' previously is now
stored in a Lisp string `new_directory' until adjustments of
multibyteness has been completed.
YAMAMOTO Mitsuharu
[EMAIL PROTECTED]
Index: src/fileio.c
===
RCS file: /cvsroot/emacs/emacs/src/fileio.c,v
retrieving revision 1.580
diff -c -p -r1.580 fileio.c
*** src/fileio.c22 Mar 2007 12:15:04 - 1.580
--- src/fileio.c10 May 2007 09:09:53 -
*** See also the function `substitute-in-fil
*** 1060,1067
int collapse_newdir = 1;
int is_escaped = 0;
#endif /* DOS_NT */
! int length;
! Lisp_Object handler, result;
int multibyte;
CHECK_STRING (name);
--- 1060,1066
int collapse_newdir = 1;
int is_escaped = 0;
#endif /* DOS_NT */
! Lisp_Object handler, new_directory, result;
int multibyte;
CHECK_STRING (name);
*** See also the function `substitute-in-fil
*** 1345,1351
default_directory if nm is not absolute, and finally collapse /./
and /foo/../ sequences.
! We set newdir to be the appropriate prefix if one is needed:
- the relevant user directory if nm starts with ~ or ~user
- the specified drive's working dir (DOS/NT only) if nm does not
start with /
--- 1344,1350
default_directory if nm is not absolute, and finally collapse /./
and /foo/../ sequences.
! We set new_directory to be the appropriate prefix if one is needed:
- the relevant user directory if nm starts with ~ or ~user
- the specified drive's working dir (DOS/NT only) if nm does not
start with /
*** See also the function `substitute-in-fil
*** 1356,1362
return an absolute name, if the final prefix is not absolute we
append it to the current working directory. */
! newdir = 0;
if (nm[0] == '~') /* prefix ~ */
{
--- 1355,1361
return an absolute name, if the final prefix is not absolute we
append it to the current working directory. */
! new_directory = Qnil;
if (nm[0] == '~') /* prefix ~ */
{
*** See also the function `substitute-in-fil
*** 1366,1373
#endif /* VMS */
|| nm[1] == 0)/* ~ by itself */
{
! if (!(newdir = (unsigned char *) egetenv (HOME)))
! newdir = (unsigned char *) ;
nm++;
#ifdef DOS_NT
collapse_newdir = 0;
--- 1365,1376
#endif /* VMS */
|| nm[1] == 0)/* ~ by itself */
{
! unsigned char *homedir = (unsigned char *) egetenv (HOME);
!
! if (homedir)
! new_directory = make_unibyte_string (homedir, strlen (homedir));
! else
! new_directory = empty_string;
nm++;
#ifdef DOS_NT
collapse_newdir = 0;
*** See also the function `substitute-in-fil
*** 1392,1398
UNBLOCK_INPUT;
if (pw)
{
! newdir = (unsigned char *) pw - pw_dir;
#ifdef VMS
nm = p + 1; /* skip the terminator */
#else
--- 1395,1403
UNBLOCK_INPUT;
if (pw)
{
! unsigned char *homedir = (unsigned char *) pw - pw_dir;
!
! new_directory = make_unibyte_string (homedir, strlen (homedir));
#ifdef VMS
nm = p + 1; /* skip the terminator */
#else
*** See also the function `substitute-in-fil
*** 1411,1433
#ifdef DOS_NT
/* On DOS and Windows, nm is absolute if a drive name was specified;
use the drive's current directory as the prefix if needed. */
! if (!newdir drive)
{
/* Get default directory if needed to make nm absolute. */
if (!IS_DIRECTORY_SEP (nm[0]))
{
! newdir = alloca (MAXPATHLEN + 1);
! if (!getdefdir (toupper (drive) - 'A' + 1, newdir))
! newdir = NULL;
}
! if (!newdir)
{
/* Either nm starts with /, or drive isn't mounted. */
! newdir = alloca (4
Re: Carbon Emacs won't start when installed in certain paths
On Tue, 08 May 2007 03:07:12 -0400, Stefan Monnier [EMAIL PROTECTED] said: If we allow non-ASCII unibyte strings for file names, maybe we need to change ENCODE_FILE and Fexpand_file_name as below, and rule out the use of concat in favor of expand-file-name to avoid implicit string-make-multibyte for non-ASCII bytes. I think it would make a lot of sense. Except I'd stay clear of string_to_multibyte and use DECODE_FILE instead. Then we have to be careful about the place to use DECODE_FILE, because it may cause GC, and the comment around the recursive call of Fexpand_file_name also applies to this situation. Though the non-ASCII unibyte `default-directory' case seems to be sufficient for the originally reported problem, we should also handle the following cases in order to make Fexpand_file_name consistent and exhaustive with respect to non-ASCII unibyte file names: 1. Case that ~ or ~user is expanded to a non-ASCII file name: This case is similar to the non-ASCII unibyte `default-directory' case. 2. Case that the argument `name' is in non-ASCII unibyte and `default-directory' is in multibyte: This case may return a wrong result either with or without my previous patch. By the way, I noticed that current_buffer-directory mentioned above is decoded with local-coding-system in command-line (startup.el) after coding systems are ready. Why not (default-)file-name-coding-system? Probably an oversight. Handa-san, could you comment on this? YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Mac OS X: colors in a terminal
On Wed, 25 Apr 2007 21:17:17 -0600, Kevin Rodgers [EMAIL PROTECTED] said: The mac/INSTALL file says: To use colors in a terminal, put the following lines in the file ~/.termcap and log in again. (snip) Is the suggestion in mac/INSTALL obsolete altogether or does it just need to be clarified? This description seems to be applicable only to Terminal.app on Mac OS X 10.1. I'll update it. Thanks for notifying. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mac/INSTALL typos
On Thu, 26 Apr 2007 12:08:54 -0400, Glenn Morris [EMAIL PROTECTED] said: Thanks. I applied your patch to both the trunk and the EMACS_22_BASE branch. I think you should alter the changelog entry to be under your name, which seems perfectly acceptable for corrections which are simple typos (ie purely factual). Large numbers of tiny changes from authors without assignments are an issue. I haven't read any of the recent bug reports, but please don't install any code from the OP. If you're not familiar with the gory details, see admin/notes/copyright, or this thread: http://lists.gnu.org/archive/html/emacs-devel/2007-04/msg00257.html Sorry, I should have noticed that, but I didn't recognize him when I read the report. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: C-char doesn't respect current keyboard layout, OS X Carbon
On Tue, 24 Apr 2007 08:27:36 +0200, Aidan Kehoe [EMAIL PROTECTED] said: So, is your Irish layout different from what is bundled with Mac OS X? Could you precisely explain what I've installed a variant of the OS X Irish layout (which is itself a variant of the British layout) in the original message means? http://www.parhasard.net/keyboard/ExtendedAidan.layout is a variant of the Irish layout, created as described here: http://developer.apple.com/technotes/tn2002/tn2056.html . I downloaded http://www.parhasard.net/keyboard/ExtendedAidan.keylayout, ^^^ then put it in /Library/Keyboard Layouts, and did re-login. But this layout did not appear in the Input Menu pane. Instead, I found the error message in console.log: uchr XML compiler: Reference to undefined action \u00a6 According to the above technical note, it means there's an error in the keylayout file. (I'm using Mac OS X 10.4.9.) Can you replace `action=' at line 722 with `output=' and try again? YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: C-char doesn't respect current keyboard layout, OS X Carbon
On Tue, 24 Apr 2007 10:29:38 +0200, Aidan Kehoe [EMAIL PROTECTED] said: Can you replace `action=' at line 722 with `output=' and try again? There’s no action= at line 722--you’re talking about ExtendedIrishAidan.keylayout, available in the same directory. Oops, sorry. Yes, what I downloaded was ExtendedIrishAidan.keylayout. I reached it by following a link in http://www.parhasard.net/keyboard/, because I couldn't find http://www.parhasard.net/keyboard/ExtendedAidan.layout. Does the modified ExtendedIrishAidan.keylayout have the same problem? I don’t get any error messages in console.log when I log in with ExtendedAidan.keylayout . Neither do I. But I couldn't reproduce the problem with US keyboard. On Mon, 23 Apr 2007 21:24:10 +0200, Aidan Kehoe [EMAIL PROTECTED] said: Interestingly, it seems to be a difference between custom layouts and the layouts that shipped with the system. If I switch to the British or US layout, the problem goes away; that is, the control key behaves as expected, given the selected key layout. All the shipped XML keylayouts are for Unicode keyboards (group=126 and id=[some negative number]), but ExtendedAidan.keylayout is for Roman (group=0). If the modified ExtendedIrishAidan.keylayout doesn't have the same problem, then I'd suspect a bug in UCKeyTranslate() with the combination of XML non-Unicode keylayout and non-US keyboard. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: C-char doesn't respect current keyboard layout, OS X Carbon
On Mon, 23 Apr 2007 21:24:10 +0200, Aidan Kehoe [EMAIL PROTECTED] said: Interestingly, it seems to be a difference between custom layouts and the layouts that shipped with the system. If I switch to the British or US layout, the problem goes away; that is, the control key behaves as expected, given the selected key layout. So, is your Irish layout different from what is bundled with Mac OS X? Could you precisely explain what I've installed a variant of the OS X Irish layout (which is itself a variant of the British layout) in the original message means? YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: C-char doesn't respect current keyboard layout, OS X Carbon
On Mon, 23 Apr 2007 00:36:03 +0200, Aidan Kehoe [EMAIL PROTECTED] said: I'm running on Mac OS X 10.4.7, under a German-language install. The default software keyboard layout associated with the installed system, and indeed my physical hardware, is also German. However, I've installed a variant of the OS X Irish layout (which is itself a variant of the British layout) and that is the currently active keyboard layout. In the input menu, the only other available keyboard is a British (UK) layout. No other account has the German keyboard available. When I type normally, this layout is respected. However, when I use the control key, it is not, and instead the German layout is used. I don't have German keyboards and I can't reproduce this with my US keyboard. Could you see if each of the following setting/patch changes the behavior? 1) (setq mac-pass-control-to-system nil) 2) Patch to macterm.c: Index: src/macterm.c === RCS file: /cvsroot/emacs/emacs/src/macterm.c,v retrieving revision 1.214 diff -c -p -r1.214 macterm.c *** src/macterm.c 13 Apr 2007 08:14:03 - 1.214 --- src/macterm.c 23 Apr 2007 02:01:01 - *** XTread_socket (sd, expected, hold_quit) *** 11321,11326 --- 11321,11331 UniChar code; UniCharCount actual_length; + #if USE_CARBON_EVENTS + GetEventParameter (eventRef, kEventParamKeyboardType, + typeUInt32, NULL, + sizeof (UInt32), NULL, keyboard_type); + #endif status = UCKeyTranslate (uchr_ptr, keycode, key_action, modifier_key_state, YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Carbon Emacs won't start when installed in certain paths
On Tue, 10 Apr 2007 10:36:08 -0400, Stefan Monnier [EMAIL PROTECTED] said: + /* At this moment, we still don't know how to decode the directory + name. So, we keep the bytes in multibyte form so that + ENCODE_FILE correctly gets the original bytes. */ Vdata_directory ! = Ffile_name_as_directory (string_to_multibyte ! (make_unibyte_string (data_dir, ! strlen (data_dir; Vdoc_directory ! = Ffile_name_as_directory (string_to_multibyte ! (make_unibyte_string (doc_dir, ! strlen (doc_dir; Why not just keep it in unibyte form? Because the current ENCODE_FILE seems to assume that file name strings are in multibyte or ASCII-only unibyte. Also, the initialization of current_buffer-directory in init_buffer (buffer.c) does the same thing. If we allow non-ASCII unibyte strings for file names, maybe we need to change ENCODE_FILE and Fexpand_file_name as below, and rule out the use of concat in favor of expand-file-name to avoid implicit string-make-multibyte for non-ASCII bytes. By the way, I noticed that current_buffer-directory mentioned above is decoded with local-coding-system in command-line (startup.el) after coding systems are ready. Why not (default-)file-name-coding-system? ;; Decode all default-directory. (if (and default-enable-multibyte-characters locale-coding-system) (save-excursion (dolist (elt (buffer-list)) (set-buffer elt) (if default-directory (setq default-directory (decode-coding-string default-directory locale-coding-system t (setq command-line-default-directory (decode-coding-string command-line-default-directory locale-coding-system t YAMAMOTO Mitsuharu [EMAIL PROTECTED] Index: src/buffer.c === RCS file: /cvsroot/emacs/emacs/src/buffer.c,v retrieving revision 1.525 diff -c -p -r1.525 buffer.c *** src/buffer.c29 Mar 2007 15:58:34 - 1.525 --- src/buffer.c11 Apr 2007 00:54:42 - *** init_buffer () *** 5211,5222 #endif /* not VMS */ current_buffer-directory = make_unibyte_string (pwd, strlen (pwd)); - if (! NILP (buffer_defaults.enable_multibyte_characters)) - /* At this moment, we still don't know how to decode the -directory name. So, we keep the bytes in multibyte form so -that ENCODE_FILE correctly gets the original bytes. */ - current_buffer-directory - = string_to_multibyte (current_buffer-directory); /* Add /: to the front of the name if it would otherwise be treated as magic. */ --- 5211,5216 Index: src/callproc.c === RCS file: /cvsroot/emacs/emacs/src/callproc.c,v retrieving revision 1.221 diff -c -p -r1.221 callproc.c *** src/callproc.c 17 Feb 2007 01:59:00 - 1.221 --- src/callproc.c 11 Apr 2007 00:54:42 - *** init_callproc_1 () *** 1522,1533 char *data_dir = egetenv (EMACSDATA); char *doc_dir = egetenv (EMACSDOC); Vdata_directory ! = Ffile_name_as_directory (build_string (data_dir ? data_dir !: PATH_DATA)); Vdoc_directory ! = Ffile_name_as_directory (build_string (doc_dir ? doc_dir !: PATH_DOC)); /* Check the EMACSPATH environment variable, defaulting to the PATH_EXEC path from epaths.h. */ --- 1522,1536 char *data_dir = egetenv (EMACSDATA); char *doc_dir = egetenv (EMACSDOC); + if (!data_dir) data_dir = PATH_DATA; + if (!doc_dir) doc_dir = PATH_DOC; + Vdata_directory ! = Ffile_name_as_directory (make_unibyte_string (data_dir, ! strlen (data_dir))); Vdoc_directory ! = Ffile_name_as_directory (make_unibyte_string (doc_dir, ! strlen (doc_dir))); /* Check the EMACSPATH environment variable, defaulting to the PATH_EXEC path from epaths.h. */ Index: src/coding.h === RCS file: /cvsroot/emacs/emacs/src/coding.h,v retrieving revision 1.83 diff -c -p -r1.83 coding.h *** src/coding.h21 Jan 2007 20:49:26 - 1.83 --- src/coding.h11 Apr 2007 00:54:42 - *** struct coding_system *** 580,592 /* Encode the file name NAME using the specified coding system for file names, if any. */ #define ENCODE_FILE(name)\ ! (! NILP (Vfile_name_coding_system
Re: Carbon Emacs won't start when installed in certain paths
On Mon, 09 Apr 2007 15:35:26 -0400, Stefan Monnier [EMAIL PROTECTED]
said:
This said, I wouldn't be surprised if building (and/or installing)
doesn't work correctly in a directory whose complete filename
contains spaces and/or non-ascii letters.
I think he is using Carbon Emacs with self-contained setting which
puts subdirectories for runtime (lisp, etc, libexec, ...) below the
Emacs.app directory so as to make the application bundle relocatable.
I'm not familiar with the self-contained setting at all (it is
designed and coded by Steven Tamm, IIUC). But I think that at least
we need to handle non-ASCII environment variables (encoded with
file-name-coding-system, not emacs-mule) such as EMACSLOADPATH in
order to deal with the case that Emacs.app is located at a non-ASCII
directory.
That requires some changes here and there. Though I just tried that,
it may not be exhaustive and I'm not sure if it is safe to use
ENCODE_FILE in init_callproc. Also, this kind of changes may not be
appropriate at this stage.
YAMAMOTO Mitsuharu
[EMAIL PROTECTED]
Index: src/callproc.c
===
RCS file: /cvsroot/emacs/emacs/src/callproc.c,v
retrieving revision 1.221
diff -c -p -r1.221 callproc.c
*** src/callproc.c 17 Feb 2007 01:59:00 - 1.221
--- src/callproc.c 10 Apr 2007 02:29:20 -
*** init_callproc_1 ()
*** 1522,1533
char *data_dir = egetenv (EMACSDATA);
char *doc_dir = egetenv (EMACSDOC);
Vdata_directory
! = Ffile_name_as_directory (build_string (data_dir ? data_dir
!: PATH_DATA));
Vdoc_directory
! = Ffile_name_as_directory (build_string (doc_dir ? doc_dir
!: PATH_DOC));
/* Check the EMACSPATH environment variable, defaulting to the
PATH_EXEC path from epaths.h. */
--- 1522,1541
char *data_dir = egetenv (EMACSDATA);
char *doc_dir = egetenv (EMACSDOC);
+ if (!data_dir) data_dir = PATH_DATA;
+ if (!doc_dir) doc_dir = PATH_DOC;
+
+ /* At this moment, we still don't know how to decode the directory
+ name. So, we keep the bytes in multibyte form so that
+ ENCODE_FILE correctly gets the original bytes. */
Vdata_directory
! = Ffile_name_as_directory (string_to_multibyte
! (make_unibyte_string (data_dir,
!strlen (data_dir;
Vdoc_directory
! = Ffile_name_as_directory (string_to_multibyte
! (make_unibyte_string (doc_dir,
!strlen (doc_dir;
/* Check the EMACSPATH environment variable, defaulting to the
PATH_EXEC path from epaths.h. */
*** init_callproc ()
*** 1605,1617
#endif
{
tempdir = Fdirectory_file_name (Vexec_directory);
! if (access (SDATA (tempdir), 0) 0)
dir_warning (Warning: arch-dependent data dir (%s) does not exist.\n,
Vexec_directory);
}
tempdir = Fdirectory_file_name (Vdata_directory);
! if (access (SDATA (tempdir), 0) 0)
dir_warning (Warning: arch-independent data dir (%s) does not exist.\n,
Vdata_directory);
--- 1613,1625
#endif
{
tempdir = Fdirectory_file_name (Vexec_directory);
! if (access (SDATA (ENCODE_FILE (tempdir)), 0) 0)
dir_warning (Warning: arch-dependent data dir (%s) does not exist.\n,
Vexec_directory);
}
tempdir = Fdirectory_file_name (Vdata_directory);
! if (access (SDATA (ENCODE_FILE (tempdir)), 0) 0)
dir_warning (Warning: arch-independent data dir (%s) does not exist.\n,
Vdata_directory);
Index: src/emacs.c
===
RCS file: /cvsroot/emacs/emacs/src/emacs.c,v
retrieving revision 1.401
diff -c -p -r1.401 emacs.c
*** src/emacs.c 3 Apr 2007 15:25:28 - 1.401
--- src/emacs.c 10 Apr 2007 02:29:20 -
*** decode_env_path (evarname, defalt)
*** 2379,2385
{
p = index (path, SEPCHAR);
if (!p) p = path + strlen (path);
! element = (p - path ? make_string (path, p - path)
: build_string (.));
/* Add /: to the front of the name
--- 2379,2389
{
p = index (path, SEPCHAR);
if (!p) p = path + strlen (path);
! /* At this moment, we still don't know how to decode the
!directory name. So, we keep the bytes in multibyte form so
!that ENCODE_FILE correctly gets the original bytes. */
! element = (p - path
!? string_to_multibyte (make_unibyte_string (path, p - path))
: build_string (.));
/* Add /: to the front of the name
Index: src/lread.c
Re: x-display-list on the Mac
On Fri, 23 Mar 2007 16:19:14 +, David Reitter [EMAIL PROTECTED] said: (x-display-screens) returns 1, and (x-display-list) returns only (Mac), despite me running two monitors with the desktop spanning across them. That's odd - I would expect to see both displays listed. The concept of screen in X11 is different from what you are thinking about. One window cannot span multiple screens. I guess you are thinking about a framebuffer in Xinerama extension. Also, (x-display-pixel-width) returns 1280, which is the width of the display on the left (main screen). How would I find out the total desktop area and the screen a particular frame is on? Can I address the different displays (or screens?) somehow? No. Because there is no Xinerama support in the X11 version, Emacs doesn't have a concept to distinguish multiple framebuffers yet. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: x-display-list on the Mac
On Sat, 24 Mar 2007 10:10:38 +0100, Jan Djärv [EMAIL PROTECTED] said:
The concept of screen in X11 is different from what you are
thinking about. One window cannot span multiple screens. I
guess you are thinking about a framebuffer in Xinerama extension.
The build he had done was --without-x.
I meant that we should not assign a different meaning to screen in
the Carbon port while there is a counterpart in X11.
No. Because there is no Xinerama support in the X11 version, Emacs
doesn't have a concept to distinguish multiple framebuffers yet.
Right, but if you have one X11 screen on two monitors, it should
return the total width. This seems to not be the case when
compiling for native OSX.
OK, how about this? x-display-mm-{width,height} are changed so as to
keep the dpi values of the main display.
YAMAMOTO Mitsuharu
[EMAIL PROTECTED]
Index: src/macfns.c
===
RCS file: /cvsroot/emacs/emacs/src/macfns.c,v
retrieving revision 1.104
diff -c -p -r1.104 macfns.c
*** src/macfns.c11 Mar 2007 06:19:29 - 1.104
--- src/macfns.c24 Mar 2007 10:10:05 -
*** If omitted or nil, that stands for the s
*** 3113,3124
#endif
{
CGSize size;
BLOCK_INPUT;
size = CGDisplayScreenSize (kCGDirectMainDisplay);
UNBLOCK_INPUT;
! return make_number ((int) (size.height + .5f));
}
#if MAC_OS_X_VERSION_MIN_REQUIRED == 1020
else
--- 3113,3126
#endif
{
CGSize size;
+ size_t height;
BLOCK_INPUT;
size = CGDisplayScreenSize (kCGDirectMainDisplay);
+ height = CGDisplayPixelsHigh (kCGDirectMainDisplay);
UNBLOCK_INPUT;
! return make_number ((int) (size.height * dpyinfo-height / height +
.5f));
}
#if MAC_OS_X_VERSION_MIN_REQUIRED == 1020
else
*** If omitted or nil, that stands for the s
*** 3149,3160
#endif
{
CGSize size;
BLOCK_INPUT;
size = CGDisplayScreenSize (kCGDirectMainDisplay);
UNBLOCK_INPUT;
! return make_number ((int) (size.width + .5f));
}
#if MAC_OS_X_VERSION_MIN_REQUIRED == 1020
else
--- 3151,3164
#endif
{
CGSize size;
+ size_t width;
BLOCK_INPUT;
size = CGDisplayScreenSize (kCGDirectMainDisplay);
+ width = CGDisplayPixelsWide (kCGDirectMainDisplay);
UNBLOCK_INPUT;
! return make_number ((int) (size.width * dpyinfo-width / width + .5f));
}
#if MAC_OS_X_VERSION_MIN_REQUIRED == 1020
else
Index: src/macterm.c
===
RCS file: /cvsroot/emacs/emacs/src/macterm.c,v
retrieving revision 1.211
diff -c -p -r1.211 macterm.c
*** src/macterm.c 18 Mar 2007 08:06:38 - 1.211
--- src/macterm.c 24 Mar 2007 10:10:06 -
*** mac_initialize_display_info ()
*** 11538,11545
but this may not be what is actually used. Mac OSX can do better. */
dpyinfo-color_p = CGDisplaySamplesPerPixel (kCGDirectMainDisplay) 1;
dpyinfo-n_planes = CGDisplayBitsPerPixel (kCGDirectMainDisplay);
! dpyinfo-height = CGDisplayPixelsHigh (kCGDirectMainDisplay);
! dpyinfo-width = CGDisplayPixelsWide (kCGDirectMainDisplay);
#else
{
GDHandle main_device_handle = LMGetMainDevice();
--- 11538,11569
but this may not be what is actually used. Mac OSX can do better. */
dpyinfo-color_p = CGDisplaySamplesPerPixel (kCGDirectMainDisplay) 1;
dpyinfo-n_planes = CGDisplayBitsPerPixel (kCGDirectMainDisplay);
! {
! CGDisplayErr err;
! CGDisplayCount ndisps, i;
! CGDirectDisplayID *displays;
!
! err = CGGetActiveDisplayList (0, NULL, ndisps);
! if (err == noErr)
! {
! displays = alloca (sizeof (CGDirectDisplayID) * ndisps);
! err = CGGetActiveDisplayList (ndisps, displays, ndisps);
! }
! if (err == noErr)
! {
! CGRect rect = CGRectMake (0, 0, 0, 0);
!
! for (i = 0; i ndisps; i++)
! rect = CGRectUnion (rect, CGDisplayBounds (displays[i]));
! dpyinfo-height = CGRectGetHeight (rect);
! dpyinfo-width = CGRectGetWidth (rect);
! }
! else
! {
! dpyinfo-height = CGDisplayPixelsHigh (kCGDirectMainDisplay);
! dpyinfo-width = CGDisplayPixelsWide (kCGDirectMainDisplay);
! }
! }
#else
{
GDHandle main_device_handle = LMGetMainDevice();
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: x-display-list on the Mac
On Sat, 24 Mar 2007 10:49:03 +, David Reitter [EMAIL PROTECTED]
said:
OK, how about this? x-display-mm-{width,height} are changed so as
to keep the dpi values of the main display.
Sure, that would make it a bit more consistent. However, the -mm-
functions weren't really my concern.
I've heard that preview-latex uses these functions to display images
in real size.
Placing frames is a difficult thing if one doesn't know what the
available screen area is (screen as in total screen, not in the X
sense).
What complicates matters is that multiple monitors may be arranged
so that the total desktop area is not rectangular. Just having
information about total width and height won't be enough. (And I
presume that is not a Mac only issue.)
Yes. Xinerama also supports such configurations.
Can the notion of display (X) approximate each monitor? In a
situation with two monitors, one could have x-display-list return
three displays: a main one (Mac), and then 1 and 2 or so for
the other two, separately. Then, x-display-mm/pixel-width/height
could either return the dimensions of the total area, or of only one
of the screens.
According to the manual page of X, the phrase `display' is usually
used to refer to collection of monitors that share a common keyboard
and pointer (mouse, tablet, etc.). In that sense, there's only one
display on a Mac regardless of the number of monitors.
Display and screen are established terms in X11, and I think we
should not abuse them. As I mentioned earlier, the concept you want
has another name framebuffer in the X11 (Xinerama) world, and I
think the right thing is to support them in a consistent way on the
relevant platforms.
YAMAMOTO Mitsuharu
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: menu events get ignored when multi-line echo area message is displayed
On Thu, 15 Mar 2007 18:22:13 +, David Reitter [EMAIL PROTECTED]
said:
A message should appear in the echo area. Then, select Help -
Copying Conditions (with the mouse). Result for me is that the
license file is NOT displayed.
Note that it works if the message displayed has only one line.
This is a test case of a more general bug where the first selection
of any (?) menu item is ignored after a multi-line message has been
displayed. It has been reported by several Aquamacs users, but the
above code reproduces the bug with an unpatched GNU Emacs (Carbon).
Thanks for minimizing the problematic case. This is because
show_help_echo called from menu_target_item_handler (in macmenu.c)
indirectly calls redisplay_internal in the above case, and then
set_frame_menubar (in macmenu.c) clears f-menu_bar_items_used.
YAMAMOTO Mitsuharu
[EMAIL PROTECTED]
*** src/xdisp.c.~1.1142.~ Sat Mar 10 10:46:41 2007
--- src/xdisp.c Fri Mar 16 17:02:48 2007
*** redisplay_internal (preserve_echo_area)
*** 10872,10878
return;
}
! #if defined (USE_X_TOOLKIT) || defined (USE_GTK)
if (popup_activated ())
return;
#endif
--- 10872,10878
return;
}
! #if defined (USE_X_TOOLKIT) || defined (USE_GTK) || defined (MAC_OS)
if (popup_activated ())
return;
#endif
*** note_mouse_highlight (f, x, y)
*** 22672,22678
struct buffer *b;
/* When a menu is active, don't highlight because this looks odd. */
! #if defined (USE_X_TOOLKIT) || defined (USE_GTK)
if (popup_activated ())
return;
#endif
--- 22672,22678
struct buffer *b;
/* When a menu is active, don't highlight because this looks odd. */
! #if defined (USE_X_TOOLKIT) || defined (USE_GTK) || defined (MAC_OS)
if (popup_activated ())
return;
#endif
*** src/macmenu.c.~1.55.~ Fri Feb 23 17:26:43 2007
--- src/macmenu.c Fri Mar 16 17:03:12 2007
*** static int menu_items_n_panes;
*** 259,264
--- 259,267
/* Current depth within submenus. */
static int menu_items_submenu_depth;
+ /* Nonzero means a menu is currently active. */
+ static int popup_activated_flag;
+
/* This is set nonzero after the user activates the menu bar, and set
to zero again after the menu bars are redisplayed by prepare_menu_bar.
While it is nonzero, all calls to set_frame_menubar go deep.
*** x_activate_menubar (f)
*** 1141,1147
--- 1144,1152
set_frame_menubar (f, 0, 1);
BLOCK_INPUT;
+ popup_activated_flag = 1;
menu_choice = MenuSelect (saved_menu_event_location);
+ popup_activated_flag = 0;
menu_id = HiWord (menu_choice);
menu_item = LoWord (menu_choice);
*** mac_menu_show (f, x, y, for_click, keyma
*** 2237,2243
--- 2242,2250
install_menu_quit_handler (MAC_MENU_POPUP_SUB, menu);
/* Display the menu. */
+ popup_activated_flag = 1;
menu_item_choice = PopUpMenuSelect (menu, pos.v, pos.h, 0);
+ popup_activated_flag = 0;
/* Get the refcon to find the correct item */
if (menu_item_choice)
*** dispose_menus (kind, id)
*** 3218,3223
--- 3225,3238
#endif /* HAVE_MENUS */
+ /* Detect if a menu is currently active. */
+
+ int
+ popup_activated ()
+ {
+ return popup_activated_flag;
+ }
+
/* The following is used by delayed window autoselection. */
DEFUN (menu-or-popup-active-p, Fmenu_or_popup_active_p,
Smenu_or_popup_active_p, 0, 0, 0,
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: scrolling up via mouse drag doesn't work
On Thu, 15 Mar 2007 19:43:07 +, David Reitter [EMAIL PROTECTED] said: Thank you, your patch works fine. Thanks for testing. Scrolling this way isn't as smooth as it is when you push an arrow button - I wonder if something could be done about this. You can customize mouse-scroll-delay (in mouse.el). YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: scrolling up via mouse drag doesn't work
On Wed, 14 Mar 2007 09:59:09 +, David Reitter [EMAIL PROTECTED] said: In a buffer with more than one page of text, move point to the end. Turn off tool-bar-mode if it isn't turned off. Display only one window in the frame. Then click and drag the mouse over the upper boundary of the window (and frame). This should cause Emacs to scroll the buffer, analogous to what it does when clicking and dragging over the bottom of the window. However, it doesn't scroll. When a tool-bar is displayed, scrolling works as intended. Thanks for the report. Could you try the patch below? YAMAMOTO Mitsuharu [EMAIL PROTECTED] *** src/macterm.c.~1.210.~ Sat Mar 10 15:26:33 2007 --- src/macterm.c Wed Mar 14 19:55:12 2007 *** note_mouse_movement (frame, pos) *** 4501,4507 rif-define_frame_cursor (frame, frame-output_data.mac-nontext_cursor); } - return 1; } /* Has the mouse moved off the glyph it was on at the last sighting? */ if (frame != last_mouse_glyph_frame --- 4501,4506 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Carbon: scroll bar rendering problem
On Sat, 3 Mar 2007 08:57:02 +, David Reitter [EMAIL PROTECTED] said: On 3 Mar 2007, at 00:58, YAMAMOTO Mitsuharu wrote: (Cocoa) Emacs.app seems to do something uncommon to other platform/toolkit ports with respect to the scroll bar width and the frame internal border width in order to get rid of the gap between the rightmost scroll bars and the right edge of the frame. But that also introduces some display glitches that are not seen on other platforms (try C-x 3 or (set-frame-parameter nil 'internal-border-width 10)). It seems that the gap appears on the left side of the buffer instead, which is much nicer. I see a scrolling glitch with C-x 3, but apart from that, nothing out of the ordinary (Emacs.app 9.0 pre-3). There is still the vertical gap between the tool-bar and the scroll-bar, but that's another story and presumably easy to fix. With (set-frame-parameter nil 'internal-border-width 10) and C-x 3, the scroll bar of the left window and the left fringe of the right window get overlapped on Emacs.app 9.0rc1. Would this be hard to do? (Andy said he was going to take a quick look at the code.) Sorry, I don't understand what you mean by `this'. If you mean porting Emacs.app code to Carbon Emacs, I'd not take a risk to make the code different from other platforms and introduce bugs like above especially at this stage. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Carbon: scroll bar rendering problem
On Sun, 25 Feb 2007 08:52:03 +, David Reitter [EMAIL PROTECTED] said: This one is specific to the Carbon port, I believe I don't think so. http://lists.gnu.org/archive/html/emacs-pretest-bug/2005-07/msg00326.html http://lists.gnu.org/archive/html/emacs-devel/2004-10/msg00291.html Actually, similar gaps can be seen at least with Xaw3d, Motif, GTK+, and W32 scroll bars. From: andy.somogyi [EMAIL PROTECTED] Date: 25 February 2007 02:39:50 GMT To: [EMAIL PROTECTED] Subject: [Aquamacs-bugs] Aquamacs scroll bar rendering problem. Hello Aquamacs seems to have a rendering problem with the right scroll bar. In Aquamacs, the right scroll bar is rendered about 10 - 15 pixels in from the right edge of the window. In the other Mac Emacs version such as Emacs.app, the right scroll bar is rendered correctly, flush with the right edge of the window. (Cocoa) Emacs.app seems to do something uncommon to other platform/toolkit ports with respect to the scroll bar width and the frame internal border width in order to get rid of the gap between the rightmost scroll bars and the right edge of the frame. But that also introduces some display glitches that are not seen on other platforms (try C-x 3 or (set-frame-parameter nil 'internal-border-width 10)). YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ 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: 4 week-old pretest bugs
On Wed, 24 Jan 2007 23:27:06 +0100, Chris Moore [EMAIL PROTECTED] said: I can't tell whether your patch has improved things or not. Behaviour looks the same with or without it - ie. fine. I'm not sure, but I think this is the change which fixed it: 2007-01-11 Jan Djärv [EMAIL PROTECTED] * alloc.c (BLOCK_INPUT_ALLOC, UNBLOCK_INPUT_ALLOC): Use pthread_equal, block/unblock SIGIO. Should I try backing that change out and seeing whether your patch alone fixes it? No. Actually, my patch backs out the essential part (the latter one) of the above change. So, in order for BLOCK_INPUT to work reliably, it seems that interrupt_input_blocked should be declared as volatile (or maybe `volatile sig_atomic_t' instead of `volatile int') because it is accessed from a signal handler. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
On Mon, 15 Jan 2007 00:01:49 +0100, Chris Moore [EMAIL PROTECTED] said:
If not, I'm more than happy to run any test cases you would like me
to try. I've tried debugging it in various ways myself, but the
timing seems to be so touchy that any attempt to observe what's
going on changes things.
Could you test if the following patch affects the stability?
YAMAMOTO Mitsuharu
[EMAIL PROTECTED]
Index: src/alloc.c
===
RCS file: /sources/emacs/emacs/src/alloc.c,v
retrieving revision 1.407
diff -c -p -r1.407 alloc.c
*** src/alloc.c 21 Jan 2007 04:18:17 - 1.407
--- src/alloc.c 23 Jan 2007 07:43:15 -
*** static pthread_mutex_t alloc_mutex;
*** 131,137
do\
{ \
if (pthread_equal (pthread_self (), main_thread)) \
! sigblock (sigmask (SIGIO)); \
pthread_mutex_lock (alloc_mutex);\
} \
while (0)
--- 131,137
do\
{ \
if (pthread_equal (pthread_self (), main_thread)) \
! BLOCK_INPUT; \
pthread_mutex_lock (alloc_mutex);\
} \
while (0)
*** static pthread_mutex_t alloc_mutex;
*** 140,146
{ \
pthread_mutex_unlock (alloc_mutex); \
if (pthread_equal (pthread_self (), main_thread)) \
! sigunblock (sigmask (SIGIO)); \
} \
while (0)
--- 140,146
{ \
pthread_mutex_unlock (alloc_mutex); \
if (pthread_equal (pthread_self (), main_thread)) \
! UNBLOCK_INPUT;\
} \
while (0)
Index: src/blockinput.h
===
RCS file: /sources/emacs/emacs/src/blockinput.h,v
retrieving revision 1.21
diff -c -p -r1.21 blockinput.h
*** src/blockinput.h14 Jan 2007 03:24:37 - 1.21
--- src/blockinput.h23 Jan 2007 07:43:15 -
*** Boston, MA 02110-1301, USA. */
*** 49,55
interrupt_input_pending to a non-zero value. If that flag is set
when input becomes unblocked, UNBLOCK_INPUT will send a new SIGIO. */
! extern int interrupt_input_blocked;
/* Nonzero means an input interrupt has arrived
during the current critical section. */
--- 49,55
interrupt_input_pending to a non-zero value. If that flag is set
when input becomes unblocked, UNBLOCK_INPUT will send a new SIGIO. */
! extern volatile int interrupt_input_blocked;
/* Nonzero means an input interrupt has arrived
during the current critical section. */
Index: src/keyboard.c
===
RCS file: /sources/emacs/emacs/src/keyboard.c,v
retrieving revision 1.890
diff -c -p -r1.890 keyboard.c
*** src/keyboard.c 21 Jan 2007 04:18:15 - 1.890
--- src/keyboard.c 23 Jan 2007 07:43:16 -
*** extern int errno;
*** 90,96
/* Variables for blockinput.h: */
/* Non-zero if interrupt input is blocked right now. */
! int interrupt_input_blocked;
/* Nonzero means an input interrupt has arrived
during the current critical section. */
--- 90,96
/* Variables for blockinput.h: */
/* Non-zero if interrupt input is blocked right now. */
! volatile int interrupt_input_blocked;
/* Nonzero means an input interrupt has arrived
during the current critical section. */
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
Could you try to see if the following patch changes the situation?
YAMAMOTO Mitsuharu
[EMAIL PROTECTED]
Index: src/alloc.c
===
RCS file: /cvsroot/emacs/emacs/src/alloc.c,v
retrieving revision 1.405
diff -c -p -r1.405 alloc.c
*** src/alloc.c 13 Nov 2006 08:20:28 - 1.405
--- src/alloc.c 9 Jan 2007 04:30:08 -
*** extern __malloc_size_t __malloc_extra_bl
*** 127,147
static pthread_mutex_t alloc_mutex;
! #define BLOCK_INPUT_ALLOC \
! do\
! { \
! if (pthread_self () == main_thread) \
! BLOCK_INPUT;\
! pthread_mutex_lock (alloc_mutex); \
! } \
while (0)
! #define UNBLOCK_INPUT_ALLOC \
! do\
! { \
! pthread_mutex_unlock (alloc_mutex);\
! if (pthread_self () == main_thread) \
! UNBLOCK_INPUT; \
! } \
while (0)
#else /* SYSTEM_MALLOC || not HAVE_GTK_AND_PTHREAD */
--- 127,147
static pthread_mutex_t alloc_mutex;
! #define BLOCK_INPUT_ALLOC \
! do \
! { \
! if (pthread_equal (pthread_self (), main_thread)) \
! BLOCK_INPUT;\
! pthread_mutex_lock (alloc_mutex); \
! } \
while (0)
! #define UNBLOCK_INPUT_ALLOC \
! do \
! { \
! pthread_mutex_unlock (alloc_mutex);\
! if (pthread_equal (pthread_self (), main_thread)) \
! UNBLOCK_INPUT; \
! } \
while (0)
#else /* SYSTEM_MALLOC || not HAVE_GTK_AND_PTHREAD */
Index: src/syssignal.h
===
RCS file: /cvsroot/emacs/emacs/src/syssignal.h,v
retrieving revision 1.43
diff -c -p -r1.43 syssignal.h
*** src/syssignal.h 6 Feb 2006 15:23:21 - 1.43
--- src/syssignal.h 9 Jan 2007 04:30:08 -
*** char *strsignal ();
*** 210,216
#ifdef HAVE_GTK_AND_PTHREAD
#define SIGNAL_THREAD_CHECK(signo) \
do { \
! if (pthread_self () != main_thread) \
{ \
/* POSIX says any thread can receive the signal. On GNU/Linux \
that is not true, but for other systems (FreeBSD at least) \
--- 210,216
#ifdef HAVE_GTK_AND_PTHREAD
#define SIGNAL_THREAD_CHECK(signo) \
do { \
! if (!pthread_equal (pthread_self (), main_thread))
\
{ \
/* POSIX says any thread can receive the signal. On GNU/Linux \
that is not true, but for other systems (FreeBSD at least) \
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mouse click into window doesn't always select frame
On Sun, 10 Dec 2006 20:06:23 -0500, Richard Stallman [EMAIL PROTECTED]
said:
Please clearly state exactly what input events are needed to make
the problem happen.
It seems like a problem that is specific to the Mac Carbon port.
Please try the following patch. If there's no problem with this for a
few days, I'll install it.
YAMAMOTO Mitsuharu
[EMAIL PROTECTED]
Index: src/macterm.c
===
RCS file: /cvsroot/emacs/emacs/src/macterm.c,v
retrieving revision 1.198
diff -c -p -r1.198 macterm.c
*** src/macterm.c 10 Dec 2006 23:16:11 - 1.198
--- src/macterm.c 11 Dec 2006 07:54:05 -
*** XTread_socket (sd, expected, hold_quit)
*** 10398,10410
break;
case inContent:
! if (
! #if TARGET_API_MAC_CARBON
! FrontNonFloatingWindow ()
! #else
! FrontWindow ()
! #endif
! != window_ptr)
SelectWindow (window_ptr);
else
{
--- 10398,10404
break;
case inContent:
! if (mac_window_to_frame (window_ptr) != dpyinfo-x_focus_frame)
SelectWindow (window_ptr);
else
{
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs/pretest/emacs-22.0.90.tar.gz on intel Mac running OS 10.4.8
On Fri, 27 Oct 2006 21:51:40 -0400, Chong Yidong [EMAIL PROTECTED] said: Could someone verify that including make-package in the tarball fixes this problem? mac/Emacs.app/Contents/Resources/Emacs.icns was also missing. I updated make-dist in CVS. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mouse-autoselect-window with menu pane
On Mon, 18 Sep 2006 09:51:22 +0200, martin rudalics [EMAIL PROTECTED] said: For macmenu.c I added a line in `x_activate_menubar' that sets f-output_data.mac-menubar_active to 1. I'm not sure know whether this is needed or useful. But note that f-output_data.mac-menubar_active is currently twice reset to zero apparently for no good reason. Could someone (YAMAMOTO Mitsuharu) please test whether my change would break anything on Mac? Menu selection functions on Mac (MenuSelect and PopUpMenuSelect) do not return until the user selects an menu item or cancels the menu selection. So I think menu-or-popup-active-p can always return Qnil on Mac. Actually, f-output_data.mac-menubar_active is not useful and menubar_selection_callback is a misnomer. I guess they were simply copied from the W32 counterparts (not by me). YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mouse-autoselect-window with menu pane
On Mon, 18 Sep 2006 11:14:54 +0200, martin rudalics [EMAIL PROTECTED]
said:
Thanks for the information. Hence
DEFUN (menu-or-popup-active-p, Fmenu_or_popup_active_p,
Smenu_or_popup_active_p, 0, 0, 0,
doc: /* Return t if a menu or popup dialog is active on selected
frame. */)
()
{
/* Always return Qnil since menu selection functions do not return
until a selection has been made or cancelled. */
return Qnil;
}
will DTRT on Mac?
If the purpose is to know if some menu is *currently* active, then the
function will DTRT because Lisp evaluation never happens during menu
selection on Mac.
But could you please try to make sure that the scenario described by
Simon Marshall which started the current thread does not occur for the
Mac port? I apologize for being paranoic here.
The welcome message is shown in the lower window, and the upper window
gets selected immediately after I select the menu item. I think the
timer has fired just after the selection.
You mean `menubar_selection_callback' is exclusively called from
`x_activate_menubar' via `do_menu_choice'? In that case, the references
to menubar_active should be removed.
Exactly. I'll do that later.
YAMAMOTO Mitsuharu
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mouse-autoselect-window with menu pane
On Mon, 18 Sep 2006 11:46:05 +0100, Marshall, Simon [EMAIL PROTECTED] said: If the purpose is to know if some menu is *currently* active, then the function will DTRT because Lisp evaluation never happens during menu selection on Mac. Does that apply to popups too? Yes. For example, what do you see with: (setq foo 0) (defun foo () (message %d (setq foo (1+ foo (setq bar (run-with-timer 1 1 'foo)) ;(cancel-timer bar) and File Open Directory... Increment of the counter is suspended during the file dialog/menu operation. And after the operation, the timer fires multiple times continuously until the counter catches up the value that it would be if no file dialog/menu were activated. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mouse-autoselect-window with menu pane
On Mon, 18 Sep 2006 23:12:29 +0200, martin rudalics [EMAIL PROTECTED] said: Increment of the counter is suspended during the file dialog/menu operation. And after the operation, the timer fires multiple times continuously until the counter catches up the value that it would be if no file dialog/menu were activated. Weird. Suppose `mouse-autoselect-window-select' cancels the timer after it fired the nth time, for some n 2. There's no reason why the timer was not cancelled when it fired the (n - 1)th time. What's even more troubling: There's no reason why the timer shouldn't fire a (n + 1)th time. My description above is about the count-up example in Simon's message. You can observe a similar behavior using the example and M-! sleep 5 RET YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: focus-follows-mouse should be nil by default on MS Windows
On Sat, 15 Jul 2006 11:47:15 +0300, Eli Zaretskii [EMAIL PROTECTED] said: The default value should still reflect what's appropriate for the platform, even if for most purposes it's ignored by the OS. The OS might not DTRT, but the behavior of Emacs code depends on the value of Emacs variables. For instance, doesn't it make a difference here? I think it does. (defun select-frame-set-input-focus (frame) Select FRAME, raise it, and set input focus, if possible. (select-frame frame) (raise-frame frame) ;; Ensure, if possible, that frame gets input focus. (cond ((eq window-system 'x) (x-focus-frame frame)) ((eq window-system 'w32) (w32-focus-frame frame))) (cond (focus-follows-mouse (set-mouse-position (selected-frame) (1- (frame-width)) 0) If so, I must ask you: did you actually tried this code? (C-x 5 o calls this function, so it would suffice to try that command.) I did try it, with both nil and t as values of focus-follows-mouse, and I don't see _any_ change in behavior whatsoever. Let me confirm one thing. The value doesn't affect the behavior with respect to the mouse position on W32, either? I'm asking because I'm thinking about setting its default to nil on Mac Carbon, because if the value is t, C-x 5 o moves the mouse pointer to the upper-right corner of the focused frame. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Carbon: window close via accessibility API is broken
On Tue, 05 Sep 2006 09:37:15 +0900, YAMAMOTO Mitsuharu [EMAIL
PROTECTED] said:
It can be handled with Carbon events in kEventClassWindow.
kEventWindowClose for the Close button. kEventWindowGetIdealSize
and kEventWindowBoundsChanged for the Maximize button. The former
is easy to handle and I'll install a handler. But the latter is not
so straightforward and it may conflict with the existing code
because kEventWindowBoundsChanged is called in various situations.
Here's a patch for the zoom button (sorry, it was not the Maximize
button).
YAMAMOTO Mitsuharu
[EMAIL PROTECTED]
*** macterm.c.~1.187.~ Tue Sep 5 10:04:06 2006
--- macterm.c Wed Sep 6 09:47:34 2006
***
*** 5805,5810
--- 5805,5861
#endif /* not TARGET_API_MAC_CARBON */
}
+ static void
+ mac_handle_origin_change (f)
+ struct frame *f;
+ {
+ x_real_positions (f, f-left_pos, f-top_pos);
+ }
+
+ static void
+ mac_handle_size_change (f, pixelwidth, pixelheight)
+ struct frame *f;
+ int pixelwidth, pixelheight;
+ {
+ int cols, rows;
+
+ cols = FRAME_PIXEL_WIDTH_TO_TEXT_COLS (f, pixelwidth);
+ rows = FRAME_PIXEL_HEIGHT_TO_TEXT_LINES (f, pixelheight);
+
+ if (cols != FRAME_COLS (f)
+ || rows != FRAME_LINES (f)
+ || pixelwidth != FRAME_PIXEL_WIDTH (f)
+ || pixelheight != FRAME_PIXEL_HEIGHT (f))
+ {
+ /* We pass 1 for DELAY since we can't run Lisp code inside of
+a BLOCK_INPUT. */
+ change_frame_size (f, rows, cols, 0, 1, 0);
+ FRAME_PIXEL_WIDTH (f) = pixelwidth;
+ FRAME_PIXEL_HEIGHT (f) = pixelheight;
+ SET_FRAME_GARBAGED (f);
+
+ /* If cursor was outside the new size, mark it as off. */
+ mark_window_cursors_off (XWINDOW (f-root_window));
+
+ /* Clear out any recollection of where the mouse highlighting
+was, since it might be in a place that's outside the new
+frame size. Actually checking whether it is outside is a
+pain in the neck, so don't try--just let the highlighting be
+done afresh with new size. */
+ cancel_mouse_face (f);
+
+ #if TARGET_API_MAC_CARBON
+ if (f-output_data.mac-hourglass_control)
+ {
+ #if USE_CG_DRAWING
+ mac_prepare_for_quickdraw (f);
+ #endif
+ MoveControl (f-output_data.mac-hourglass_control,
+ pixelwidth - HOURGLASS_WIDTH, 0);
+ }
+ #endif
+ }
+ }
/* Calculate the absolute position in frame F
***
*** 5885,5891
ConstrainWindowToScreen (FRAME_MAC_WINDOW (f), kWindowTitleBarRgn,
kWindowConstrainMoveRegardlessOfFit
| kWindowConstrainAllowPartial, NULL, NULL);
! x_real_positions (f, f-left_pos, f-top_pos);
#else
{
Rect inner, outer, screen_rect, dummy;
--- 5936,5945
ConstrainWindowToScreen (FRAME_MAC_WINDOW (f), kWindowTitleBarRgn,
kWindowConstrainMoveRegardlessOfFit
| kWindowConstrainAllowPartial, NULL, NULL);
! #if USE_CARBON_EVENTS
! if (!NILP (tip_frame) XFRAME (tip_frame) == f)
! #endif
! mac_handle_origin_change (f);
#else
{
Rect inner, outer, screen_rect, dummy;
***
*** 5959,6008
x_wm_set_size_hint (f, (long) 0, 0);
SizeWindow (FRAME_MAC_WINDOW (f), pixelwidth, pixelheight, 0);
- #if TARGET_API_MAC_CARBON
- if (f-output_data.mac-hourglass_control)
- {
- #if USE_CG_DRAWING
- mac_prepare_for_quickdraw (f);
- #endif
- MoveControl (f-output_data.mac-hourglass_control,
- pixelwidth - HOURGLASS_WIDTH, 0);
- }
- #endif
! /* Now, strictly speaking, we can't be sure that this is accurate,
! but the window manager will get around to dealing with the size
! change request eventually, and we'll hear how it went when the
! ConfigureNotify event gets here.
!
! We could just not bother storing any of this information here,
! and let the ConfigureNotify event set everything up, but that
! might be kind of confusing to the Lisp code, since size changes
! wouldn't be reported in the frame parameters until some random
! point in the future when the ConfigureNotify event arrives.
!
! We pass 1 for DELAY since we can't run Lisp code inside of
! a BLOCK_INPUT. */
! change_frame_size (f, rows, cols, 0, 1, 0);
! FRAME_PIXEL_WIDTH (f) = pixelwidth;
! FRAME_PIXEL_HEIGHT (f) = pixelheight;
!
! /* We've set {FRAME,PIXEL}_{WIDTH,HEIGHT} to the values we hope to
! receive in the ConfigureNotify event; if we get what we asked
! for, then the event won't cause the screen to become garbaged, so
! we have to make sure to do it here. */
! SET_FRAME_GARBAGED (f);
!
! XFlush (FRAME_X_DISPLAY (f));
!
! /* If cursor was outside the new size, mark it as off. */
! mark_window_cursors_off (XWINDOW (f
Re: silent PC vs. emacs
On Mon, 04 Sep 2006 05:50:23 -0400, Richard Stallman [EMAIL PROTECTED]
said:
/* Install an asynchronous timer that processes Xt timeout
events every 0.1s. This is necessary because some widget
sets use timeouts internally, for example the LessTif menu
bar, or the Xaw3d scroll bar. When Xt timouts aren't
processed, these widgets don't behave normally. */
Would it be safe to turn this off if no X events have been received
for a certain time? I don't know.
As for Xt, the callback function is meaningful only when either of
some two variables (`toolkit_scroll_bar_interaction' and
`popup_activated_flag') is set. So, I think we can externalize the
condition and use a non-continuous timer instead of a continuous one.
YAMAMOTO Mitsuharu
[EMAIL PROTECTED]
*** xmenu.c.~1.307.~Thu Jun 1 18:13:30 2006
--- xmenu.c Mon Sep 4 22:47:30 2006
***
*** 1182,1187
--- 1182,1191
{
menu_items_inuse = in_use ? Qt : Qnil;
popup_activated_flag = in_use;
+ #ifdef USE_X_TOOLKIT
+ if (popup_activated_flag)
+ x_activate_timeout_atimer ();
+ #endif
}
/* Wait for an X event to arrive or for a timer to expire. */
***
*** 1498,1503
--- 1502,1510
XtPointer client_data;
{
popup_activated_flag = 1;
+ #ifdef USE_X_TOOLKIT
+ x_activate_timeout_atimer ();
+ #endif
}
#endif
***
*** 2798,2803
--- 2805,2811
/* Display the menu. */
lw_popup_menu (menu, (XEvent *) dummy);
popup_activated_flag = 1;
+ x_activate_timeout_atimer ();
{
int fact = 4 * sizeof (LWLIB_ID);
***
*** 3175,3180
--- 3183,3189
/* Display the dialog box. */
lw_pop_up_all_widgets (dialog_id);
popup_activated_flag = 1;
+ x_activate_timeout_atimer ();
/* Process events that apply to the dialog box.
Also handle timers. */
*** xterm.h.~1.186.~Thu Aug 17 15:57:55 2006
--- xterm.h Mon Sep 4 22:46:06 2006
***
*** 1001,1006
--- 1001,1007
extern int x_alloc_lighter_color_for_widget __P ((Widget, Display*, Colormap,
unsigned long *,
double, int));
+ extern void x_activate_timeout_atimer P_ ((void));
#endif
extern void x_query_colors P_ ((struct frame *f, XColor *, int));
extern void x_query_color P_ ((struct frame *f, XColor *));
*** xterm.c.~1.924.~Fri Aug 25 10:45:51 2006
--- xterm.c Mon Sep 4 22:46:52 2006
***
*** 4092,4097
--- 4092,4100
/* Make Xt timeouts work while the scroll bar is active. */
toolkit_scroll_bar_interaction = 1;
+ #ifdef USE_X_TOOLKIT
+ x_activate_timeout_atimer ();
+ #endif
/* Setting the event mask to zero means that the message will
be sent to the client that created the window, and if that
***
*** 10129,10134
--- 10132,10142
{-mc, *pointerColor, XrmoptionSepArg, (XtPointer) NULL},
{-cr, *cursorColor, XrmoptionSepArg, (XtPointer) NULL}
};
+
+ /* Whether atimer for Xt timeouts is activated or not. */
+
+ static int x_timeout_atimer_activated_flag;
+
#endif /* USE_X_TOOLKIT */
static int x_initialized;
***
*** 10810,10822
x_process_timeouts (timer)
struct atimer *timer;
{
if (toolkit_scroll_bar_interaction || popup_activated ())
{
- BLOCK_INPUT;
while (XtAppPending (Xt_app_con) XtIMTimer)
XtAppProcessEvent (Xt_app_con, XtIMTimer);
! UNBLOCK_INPUT;
}
}
#endif /* USE_X_TOOLKIT */
--- 10818,10857
x_process_timeouts (timer)
struct atimer *timer;
{
+ BLOCK_INPUT;
if (toolkit_scroll_bar_interaction || popup_activated ())
{
while (XtAppPending (Xt_app_con) XtIMTimer)
XtAppProcessEvent (Xt_app_con, XtIMTimer);
! /* Reactivate the atimer for next time. */
! x_activate_timeout_atimer ();
}
+ else
+ x_timeout_atimer_activated_flag = 0;
+ UNBLOCK_INPUT;
+ }
+
+ /* Install an asynchronous timer that processes Xt timeout events
+every 0.1s as long as either `toolkit_scroll_bar_interaction' or
+`popup_activated_flag' (in xmenu.c) is set. Make sure to call this
+function whenever these variables are set. This is necessary
+because some widget sets use timeouts internally, for example the
+LessTif menu bar, or the Xaw3d scroll bar. When Xt timeouts aren't
+processed, these widgets don't behave normally. */
+
+ void
+ x_activate_timeout_atimer ()
+ {
+ BLOCK_INPUT;
+ if (!x_timeout_atimer_activated_flag)
+ {
+ EMACS_TIME interval;
+
+ EMACS_SET_SECS_USECS (interval, 0, 10);
+ start_atimer (ATIMER_RELATIVE, interval, x_process_timeouts, 0);
+ x_timeout_atimer_activated_flag = 1;
+ }
+ UNBLOCK_INPUT
Re: silent PC vs. emacs
On Mon, 04 Sep 2006 23:15:52 +0900, YAMAMOTO Mitsuharu [EMAIL
PROTECTED] said:
So, I think we can externalize the condition and use a
non-continuous timer instead of a continuous one.
Sorry. There was a mistake in the previous patch: the variable
`x_timeout_atimer_activated_flag' was not properly reset. Please
replace it with the following one.
YAMAMOTO Mitsuharu
[EMAIL PROTECTED]
*** xmenu.c.~1.307.~Thu Jun 1 18:13:30 2006
--- xmenu.c Mon Sep 4 22:47:30 2006
***
*** 1182,1187
--- 1182,1191
{
menu_items_inuse = in_use ? Qt : Qnil;
popup_activated_flag = in_use;
+ #ifdef USE_X_TOOLKIT
+ if (popup_activated_flag)
+ x_activate_timeout_atimer ();
+ #endif
}
/* Wait for an X event to arrive or for a timer to expire. */
***
*** 1498,1503
--- 1502,1510
XtPointer client_data;
{
popup_activated_flag = 1;
+ #ifdef USE_X_TOOLKIT
+ x_activate_timeout_atimer ();
+ #endif
}
#endif
***
*** 2798,2803
--- 2805,2811
/* Display the menu. */
lw_popup_menu (menu, (XEvent *) dummy);
popup_activated_flag = 1;
+ x_activate_timeout_atimer ();
{
int fact = 4 * sizeof (LWLIB_ID);
***
*** 3175,3180
--- 3183,3189
/* Display the dialog box. */
lw_pop_up_all_widgets (dialog_id);
popup_activated_flag = 1;
+ x_activate_timeout_atimer ();
/* Process events that apply to the dialog box.
Also handle timers. */
*** xterm.h.~1.186.~Thu Aug 17 15:57:55 2006
--- xterm.h Mon Sep 4 22:46:06 2006
***
*** 1001,1006
--- 1001,1007
extern int x_alloc_lighter_color_for_widget __P ((Widget, Display*, Colormap,
unsigned long *,
double, int));
+ extern void x_activate_timeout_atimer P_ ((void));
#endif
extern void x_query_colors P_ ((struct frame *f, XColor *, int));
extern void x_query_color P_ ((struct frame *f, XColor *));
*** xterm.c.~1.924.~Fri Aug 25 10:45:51 2006
--- xterm.c Tue Sep 5 09:13:42 2006
***
*** 4092,4097
--- 4092,4100
/* Make Xt timeouts work while the scroll bar is active. */
toolkit_scroll_bar_interaction = 1;
+ #ifdef USE_X_TOOLKIT
+ x_activate_timeout_atimer ();
+ #endif
/* Setting the event mask to zero means that the message will
be sent to the client that created the window, and if that
***
*** 10129,10134
--- 10132,10142
{-mc, *pointerColor, XrmoptionSepArg, (XtPointer) NULL},
{-cr, *cursorColor, XrmoptionSepArg, (XtPointer) NULL}
};
+
+ /* Whether atimer for Xt timeouts is activated or not. */
+
+ static int x_timeout_atimer_activated_flag;
+
#endif /* USE_X_TOOLKIT */
static int x_initialized;
***
*** 10810,10822
x_process_timeouts (timer)
struct atimer *timer;
{
if (toolkit_scroll_bar_interaction || popup_activated ())
{
- BLOCK_INPUT;
while (XtAppPending (Xt_app_con) XtIMTimer)
XtAppProcessEvent (Xt_app_con, XtIMTimer);
! UNBLOCK_INPUT;
}
}
#endif /* USE_X_TOOLKIT */
--- 10818,10856
x_process_timeouts (timer)
struct atimer *timer;
{
+ BLOCK_INPUT;
+ x_timeout_atimer_activated_flag = 0;
if (toolkit_scroll_bar_interaction || popup_activated ())
{
while (XtAppPending (Xt_app_con) XtIMTimer)
XtAppProcessEvent (Xt_app_con, XtIMTimer);
! /* Reactivate the atimer for next time. */
! x_activate_timeout_atimer ();
! }
! UNBLOCK_INPUT;
! }
!
! /* Install an asynchronous timer that processes Xt timeout events
!every 0.1s as long as either `toolkit_scroll_bar_interaction' or
!`popup_activated_flag' (in xmenu.c) is set. Make sure to call this
!function whenever these variables are set. This is necessary
!because some widget sets use timeouts internally, for example the
!LessTif menu bar, or the Xaw3d scroll bar. When Xt timeouts aren't
!processed, these widgets don't behave normally. */
!
! void
! x_activate_timeout_atimer ()
! {
! BLOCK_INPUT;
! if (!x_timeout_atimer_activated_flag)
! {
! EMACS_TIME interval;
!
! EMACS_SET_SECS_USECS (interval, 0, 10);
! start_atimer (ATIMER_RELATIVE, interval, x_process_timeouts, 0);
! x_timeout_atimer_activated_flag = 1;
}
+ UNBLOCK_INPUT;
}
#endif /* USE_X_TOOLKIT */
***
*** 10922,10938
XtCacheByDisplay, cvt_pixel_dtor);
XtAppSetFallbackResources (Xt_app_con, Xt_default_resources);
-
- /* Install an asynchronous timer that processes Xt timeout events
- every 0.1s. This is necessary because some widget sets use
- timeouts internally, for example the LessTif menu bar, or the
- Xaw3d scroll
Re: Carbon: window close via accessibility API is broken
On Mon, 4 Sep 2006 16:50:45 +0100, David Reitter [EMAIL PROTECTED] said: Emacs (Carbon port) seems to have trouble with Accessibility API events. - AXPress action on the Closer button of a frame doesn't do anything - AXPress action on Minimize seems to work - AXPress action on Maximize produces garbage, with the window width being wrong. Subsequent manual redraws or scrolling lead to worse garbage. (I can make a screenshot available if needed.) Thanks for the report. I could reproduce the problem. I looked into the reference documents he mentions but I couldn't see what events we're waiting for, and why this click on the window closer needs to be dealt with separately (does it?). It can be handled with Carbon events in kEventClassWindow. kEventWindowClose for the Close button. kEventWindowGetIdealSize and kEventWindowBoundsChanged for the Maximize button. The former is easy to handle and I'll install a handler. But the latter is not so straightforward and it may conflict with the existing code because kEventWindowBoundsChanged is called in various situations. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: shift-space registers as space under Mac OS X
On Mon, 4 Sep 2006 10:36:37 -0400, Bill Rising [EMAIL PROTECTED] said: If I type C-h k S-SPC in the old build, the help starts with SPC (translated from S-SPC) ... If I type the same sequence in the nightly build, the help starts with SPC... without any mention of a translation Thanks for the report. I've just installed a fix. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: silent PC vs. emacs
On Sat, 02 Sep 2006 14:19:09 -0700, Dan Nicolaescu [EMAIL PROTECTED]
said:
. The blink-cursor mode uses a timer (that probably explains setitmer
and SIGALRM)
. select calls are issued when Emacs enters the idle loop
. The rest might be because the blink-cursor mode causes signals,
which then require various system calls, like select, to be
restarted
The same thing happens when blink-cursor-mode is turned off. It is a
bit less frequent, but still a few times a second.
You mean, you still have setitimer and SIGALRMs, even without
blink-cursor-mode?
Yes, that's exactly what I mean.
SIGALRM has nothing to do with blink-cursor-mode (the timer mechanism
in Emacs, in general). I think you were observing the following
asynchronous timer that is set in x_initialize (xterm.c) when
USE_X_TOOLKIT is defined.
/* Install an asynchronous timer that processes Xt timeout events
every 0.1s. This is necessary because some widget sets use
timeouts internally, for example the LessTif menu bar, or the
Xaw3d scroll bar. When Xt timouts aren't processed, these
widgets don't behave normally. */
{
EMACS_TIME interval;
EMACS_SET_SECS_USECS (interval, 0, 10);
start_atimer (ATIMER_CONTINUOUS, interval, x_process_timeouts, 0);
}
YAMAMOTO Mitsuharu
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: proxy icon and moved files
On Wed, 23 Aug 2006 12:53:12 +0100, David Reitter [EMAIL PROTECTED] said: The proxy icon is set by giving the corresponding alias record to SetWindowProxyAlias. But the correspondence between file name and alias record seems to be not persistent. Actually, the latter takes care of renaming. So if you keep alias records, then you refer to the files by FSRef, correct? I'm not sure, but maybe not. Technical Note TN2078 says: Like FSSpecs, FSRefs are not guaranteed to be valid across boots in Mac OS 9 or Mac OS X, across processes in Mac OS X, or even across separate launches of the same application in Mac OS X, so don't use them when you need persistent storage. For persistent storage, aliases are still the recommended approach. (http://developer.apple.com/technotes/tn2002/tn2078.html) Could standard tracking of file changes (e.g. user changes file name or moves the file in Finder, Emacs updates its records automatically) then be easily implemented? Yes. You can see the value that the variable `alias' is bound to tracks the renamed file in the following code: (let* ((file1 (make-temp-file foo)) (file2 (concat file1 -renamed)) (alias (mac-coerce-ae-data 'undecoded-file-name (encode-coding-string file1 'utf-8) alis))) (rename-file file1 file2) (prog1 (decode-coding-string (mac-coerce-ae-data alis alias 'undecoded-file-name) 'utf-8) (delete-file file2))) Could you try the following patch? It tries to see if the alias record that is currently set is updated by the current file name. I tried it and it seems to work - I can't reproduce the problem anymore. Thanks for testing. I've installed the change. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: proxy icon and moved files
On Mon, 21 Aug 2006 16:27:58 +0100, David Reitter [EMAIL PROTECTED]
said:
Dragging and dropping the Carbon proxy icon to a Finder window
sometimes saves the backup file (foo.txt~) instead of the actual
file.
I could reproduce this with a current build. I tried to locate the
code that handles these things, but it's not immediately evident why
a local copy of the file name for the frame is kept in macterm.c
(file_name) and why it isn't updated correctly (if that is the
cause).
The intended reason why a local copy is kept is to avoid needless data
conversion and display update as much as possible. And the local copy
itself is updated correctly.
The proxy icon is set by giving the corresponding alias record to
SetWindowProxyAlias. But the correspondence between file name and
alias record seems to be not persistent. Actually, the latter takes
care of renaming.
Could you try the following patch? It tries to see if the alias
record that is currently set is updated by the current file name.
YAMAMOTO Mitsuharu
[EMAIL PROTECTED]
Index: src/macfns.c
===
RCS file: /cvsroot/emacs/emacs/src/macfns.c,v
retrieving revision 1.90
diff -c -p -r1.90 macfns.c
*** src/macfns.c28 Jun 2006 08:30:16 - 1.90
--- src/macfns.c22 Aug 2006 05:35:29 -
*** static void
*** 1945,2007
mac_update_proxy_icon (f)
struct frame *f;
{
Lisp_Object file_name =
XBUFFER (XWINDOW (FRAME_SELECTED_WINDOW (f))-buffer)-filename;
Window w = FRAME_MAC_WINDOW (f);
!
! if (FRAME_FILE_NAME (f) == NULL !STRINGP (file_name))
! return;
! if (FRAME_FILE_NAME (f) STRINGP (file_name)
!strcmp (FRAME_FILE_NAME (f), SDATA (file_name)) == 0)
! return;
!
! if (FRAME_FILE_NAME (f))
! {
! xfree (FRAME_FILE_NAME (f));
! FRAME_FILE_NAME (f) = NULL;
! }
BLOCK_INPUT;
if (STRINGP (file_name))
{
- OSStatus err;
AEDesc desc;
Lisp_Object encoded_file_name = ENCODE_FILE (file_name);
! #ifdef MAC_OS8
SetPortWindowPort (w);
- #endif
err = AECoercePtr (TYPE_FILE_NAME, SDATA (encoded_file_name),
!SBYTES (encoded_file_name), typeAlias, desc);
if (err == noErr)
{
! Size size = AEGetDescDataSize (desc);
! AliasHandle alias = (AliasHandle) NewHandle (size);
!
! if (alias == NULL)
! err = memFullErr;
! else
! {
! HLock ((Handle) alias);
! err = AEGetDescData (desc, *alias, size);
! HUnlock ((Handle) alias);
! if (err == noErr)
! err = SetWindowProxyAlias (w, alias);
! DisposeHandle ((Handle) alias);
! }
AEDisposeDesc (desc);
}
if (err == noErr)
{
! FRAME_FILE_NAME (f) = xmalloc (SBYTES (file_name) + 1);
! strcpy (FRAME_FILE_NAME (f), SDATA (file_name));
}
}
! if (FRAME_FILE_NAME (f) == NULL)
RemoveWindowProxy (w);
UNBLOCK_INPUT;
}
#endif
--- 1945,2024
mac_update_proxy_icon (f)
struct frame *f;
{
+ OSStatus err;
Lisp_Object file_name =
XBUFFER (XWINDOW (FRAME_SELECTED_WINDOW (f))-buffer)-filename;
Window w = FRAME_MAC_WINDOW (f);
! AliasHandle alias = NULL;
BLOCK_INPUT;
+ err = GetWindowProxyAlias (w, alias);
+ if (err == errWindowDoesNotHaveProxy !STRINGP (file_name))
+ goto out;
+
if (STRINGP (file_name))
{
AEDesc desc;
+ #ifdef MAC_OSX
+ FSRef fref;
+ #else
+ FSSpec fss;
+ #endif
+ Boolean changed;
Lisp_Object encoded_file_name = ENCODE_FILE (file_name);
! #ifdef MAC_OSX
! err = AECoercePtr (TYPE_FILE_NAME, SDATA (encoded_file_name),
!SBYTES (encoded_file_name), typeFSRef, desc);
! #else
SetPortWindowPort (w);
err = AECoercePtr (TYPE_FILE_NAME, SDATA (encoded_file_name),
!SBYTES (encoded_file_name), typeFSS, desc);
! #endif
if (err == noErr)
{
! #ifdef MAC_OSX
! err = AEGetDescData (desc, fref, sizeof (FSRef));
! #else
! err = AEGetDescData (desc, fss, sizeof (FSSpec));
! #endif
AEDisposeDesc (desc);
}
if (err == noErr)
{
! if (alias)
! {
! #ifdef MAC_OSX
! err = FSUpdateAlias (NULL, fref, alias, changed);
! #else
! err = UpdateAlias (NULL, fss, alias, changed);
! #endif
! }
! if (err != noErr || alias == NULL)
! {
! if (alias)
! DisposeHandle ((Handle) alias);
! #ifdef MAC_OSX
! err = FSNewAliasMinimal (fref, alias);
! #else
! err = NewAliasMinimal (fss, alias);
! #endif
! changed = true;
! }
}
+ if (err == noErr
Re: Lockup
On Fri, 11 Aug 2006 08:36:39 +0200, Jan Djärv [EMAIL PROTECTED] said: A signal yes, but I was thinking of this scenario: A Gnome thread does malloc, gets the mutex lock and enters the malloc code. A signal is delivered (in the main thread as you point out) and enters malloc also. This situation is exactly like the one with the lockup, but here we can't use BLOCK_INPUT around the malloc related functions because they are in the Gnome code. I think such a case just behaves like a usual mutual exclusion between multiple threads: one thread acquires a mutex, and the other blocks until it is released. I agree with your assumtion that the lockuo occurs because the signal handler and the interrupted therad are calling pthread_mutex_(un)lock for the same mutex. But BLOCK_INPUT does not help, because Gnome code does not have it. That's not a problem because Gnome threads (non-main threads) never execute pthread_mutex_(un)lock in the signal hander context. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Lockup
On Fri, 11 Aug 2006 09:04:34 +0200, David Kastrup [EMAIL PROTECTED] said: YAMAMOTO Mitsuharu [EMAIL PROTECTED] writes: Yes, pthread_mutex_(un)lock is not async-signal-safe. But we are already using such functions as malloc in the signal handler context (with the help of BLOCK_INPUT). I guess calling pthread_mutex_(un)lock in the signal handler context is safe in reality unless the interrupted thread is also executing pthread_mutex_(un)lock for the same mutex. I guess ... safe in reality unless ... Maybe I have been around programmers too long, but I don't find this exactly reassuring. Yeah. IEEE Std 1003.1 provides a table of async-signal-safe functions (those can be called safely within a signal handler), and neither malloc nor pthread_mutex_(un)lock is such functions. All functions not in the above table are considered to be unsafe with respect to signals. In the presence of signals, all functions defined by this volume of IEEE Std 1003.1-2001 shall behave as defined when called from or interrupted by a signal-catching function, with a single exception: when a signal interrupts an unsafe function and the signal-catching function calls an unsafe function, the behavior is undefined. (http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html) We already have malloc calls in the signal handler context with the assumption that it is safe to call unless the signal interrupts malloc-related functions. So I think it's not that bad to also put reasonable assumptions to pthread_mutex_(un)lock. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Lockup
On Fri, 11 Aug 2006 10:09:49 +0200, Jan Djärv [EMAIL PROTECTED] said: That's not a problem because Gnome threads (non-main threads) never execute pthread_mutex_(un)lock in the signal hander context. That does not help, the main thread executes in signal handler context sometimes. And in that case, both the Gnome thread and the signal handler may be executing (un)lock_mutex on the same mutex. I don't think this causes a problem. The signal handler is executed in the main thread that is different from the Gnome thread. And as I quoted from IEEE Std 1003.1 in another message, a pthread_mutex_(un)lock call in the signal hander context should work as usual unless the signal interrupted an unsafe function. The condition unless the signal interrupted an unsafe function is too strict in reality. My guess was that it could be relaxed to unless the signal interrupted a pthread_mutex_(un)lock call for the same mutex. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Lockup
On Thu, 10 Aug 2006 08:20:24 +0200, Jan Djärv [EMAIL PROTECTED] said: Hi, I just had a lockup occuring. Here is a backtrace: I've checked in a fix, but I beleive the race condition still exists on multiprocessor machines. I can't see a way to fix that except move to SYNC_INPUT. Maybe I'm missing something, but doesn't adding BLOCK_INPUT around closedir (and opendir) help? YAMAMOTO Mitsuharu [EMAIL PROTECTED] #22 0x080cac12 in XTread_socket (sd=0, expected=1, hold_quit=0xbfabf5ac) at /home/tmp/emacs/src/xterm.c:7067 #23 0x080f90dc in read_avail_input (expected=1) at /home/tmp/emacs/src/keyboard.c:6737 #24 0x080f9283 in handle_async_input () at /home/tmp/emacs/src/keyboard.c:6883 #25 0x080f9317 in input_available_signal (signo=29) at /home/tmp/emacs/src/keyboard.c:6925 #26 signal handler called #27 0xb795d27d in pthread_mutex_unlock () from /lib/tls/i686/cmov/libpthread.so.0 #28 0xb77a62f5 in free () from /lib/tls/i686/cmov/libc.so.6 #29 0xb77caa08 in closedir () from /lib/tls/i686/cmov/libc.so.6 #30 0x08122c57 in directory_files_internal_unwind (dh=161026626) at /home/tmp/emacs/src/dired.c:137 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Lockup
On Thu, 10 Aug 2006 10:11:55 +0200, Jan Djärv [EMAIL PROTECTED] said:
Maybe I'm missing something, but doesn't adding BLOCK_INPUT around
closedir (and opendir) help?
In this particular case it would help, but in general the problem is
that the signal handler gets called when the main thread is
executing in the mutex code (pthread_mutex_unlock). Later when the
signal handler tries to get the mutex, it locks up,
My intention was that the above scenario would be avoided with
BLOCK_INPUT around functions that may call malloc-related functions.
it is actually not allowed to call mutex functions from a signal
handler. The mutex is there to protect from other (Gnome) threads
that also call malloc/free.
But if a Gnome thread has the mutex and before it has blocked
signals, the signal handler is run in parallell on another
processor, there will be problems. If we move to SYNC_INPUT there
will be no malloc/free called in the signal handler and we only need
the mutex to hamdle concurrent access.
The current version would cause such a problem because now
BLOCK_INPUT_ALLOC and UNBLOCK_INPUT_ALLOC are no-op in a signal
handler.
How about just changing the order of lock/unlock and
BLOCK_INPUT/UNBLOCK_INPUT in the previous version of
BLOCK_INPUT_ALLOC/UNBLOCK_INPUT_ALLOC?
#define BLOCK_INPUT_ALLOC \
do\
{ \
if (pthread_self () == main_thread) \
BLOCK_INPUT;\
pthread_mutex_lock (alloc_mutex);\
} \
while (0)
#define UNBLOCK_INPUT_ALLOC \
do\
{ \
pthread_mutex_unlock (alloc_mutex); \
if (pthread_self () == main_thread) \
UNBLOCK_INPUT; \
} \
while (0)
YAMAMOTO Mitsuharu
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Lockup
On Thu, 10 Aug 2006 13:17:03 +0200, Jan Djärv [EMAIL PROTECTED] said: My intention was that the above scenario would be avoided with BLOCK_INPUT around functions that may call malloc-related functions. It does not help if the calling thread is one of the Gnoem threads. But a signal delivered to a non-main thread is redirected to the main thread by SIGNAL_THREAD_CHECK. How about just changing the order of lock/unlock and BLOCK_INPUT/UNBLOCK_INPUT in the previous version of BLOCK_INPUT_ALLOC/UNBLOCK_INPUT_ALLOC? That would mean that lock/unlock mutex functions are called in the signal handler context, which is not allowed according to the documentation. Yes, pthread_mutex_(un)lock is not async-signal-safe. But we are already using such functions as malloc in the signal handler context (with the help of BLOCK_INPUT). I guess calling pthread_mutex_(un)lock in the signal handler context is safe in reality unless the interrupted thread is also executing pthread_mutex_(un)lock for the same mutex. I think it's better than the current one, i.e., not protecting shared resources such as __malloc_hook in the signal handler context. (Of course SYNC_INPUT is the right direction, but the current plan is not enabling it in the next release as far as I understand.) YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash when launched -nw on Mac OS X, compiled with gcc 4.0.1
On Wed, 26 Jul 2006 09:33:10 +1200, Nick Roberts [EMAIL PROTECTED] said: My guess would be that your processor doesn't support -mpowerpc-gpopt Most likely. /usr/include/gcc/darwin/4.0/ppc_intrnsics.h says: /* * __fsqrt - Floating-Point Square Root (Double-Precision) * * WARNING: Illegal instruction for PowerPC 603, 604, 750, 7400, 7410, * 7450, and 7455 */ /* * __fsqrts - Floating-Point Square Root Single-Precision * * WARNING: Illegal instruction for PowerPC 603, 604, 750, 7400, 7410, * 7450, and 7455 */ YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Fn-. does not produce , on German keyboard
On Tue, 18 Jul 2006 00:57:41 +0200, Peter Dyballa [EMAIL PROTECTED] said: The Fn key is also used to switch part of the keyboard into a numerical keypad mode. The keys `m,.-´ then become `0,,+´, but Carbon Emacs 23.0.0 produces `0,.+´. Carbon Emacs 22.0.50 behaves correctly. They both insert `,' on my side. But I noticed that there is another problem: keypad keys does not generate kp-* events. I've just installed a fix to the trunk so that Fn-. or the keypad key next to `0' generates kp-decimal with US keyboards, and kp-separator with German or French keyboards. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Reentrant call to malloc/free
On Thu, 06 Jul 2006 09:53:57 +0900, YAMAMOTO Mitsuharu [EMAIL
PROTECTED] said:
I've once posted a (not complete) list of Darwin library functions
that may call malloc-related functions but are not protected by
BLOCK_INPUT:
localtime, gmtime, ctime, opendir, getc, getaddrinfo, fwrite,
mkstemp fclose, closedir, freeaddrinfo, mktime (not used as of
2004-09)
(http://lists.gnu.org/archive/html/emacs-devel/2004-09/msg00074.html)
I cannot detect `getgrgid' as such a function, but I guess this is
due to the difference in name service backends (NIS, LDAP, ...).
Sorry, I could. So it has nothing to do with the type of backends.
Also, I found that getpwuid/getpwnam/getgrgid in both glibc and
FreeBSD libc called malloc-related functions. So I think it's
reasonable to put BLOCK_INPUTs around them. Objections?
YAMAMOTO Mitsuharu
[EMAIL PROTECTED]
Index: src/Makefile.in
===
RCS file: /cvsroot/emacs/emacs/src/Makefile.in,v
retrieving revision 1.327
diff -c -p -r1.327 Makefile.in
*** src/Makefile.in 18 May 2006 17:05:36 - 1.327
--- src/Makefile.in 8 Jul 2006 05:30:06 -
*** pre-crt0.o: pre-crt0.c
*** 1108,1114
ecrt0.o: ecrt0.c $(config_h)
CRT0_COMPILE ${srcdir}/ecrt0.c
dired.o: dired.c commands.h buffer.h $(config_h) charset.h coding.h regex.h \
!systime.h
dispnew.o: dispnew.c systty.h systime.h commands.h process.h frame.h \
window.h buffer.h dispextern.h termchar.h termopts.h termhooks.h cm.h \
disptab.h indent.h intervals.h \
--- 1108,1114
ecrt0.o: ecrt0.c $(config_h)
CRT0_COMPILE ${srcdir}/ecrt0.c
dired.o: dired.c commands.h buffer.h $(config_h) charset.h coding.h regex.h \
!systime.h blockinput.h
dispnew.o: dispnew.c systty.h systime.h commands.h process.h frame.h \
window.h buffer.h dispextern.h termchar.h termopts.h termhooks.h cm.h \
disptab.h indent.h intervals.h \
*** doprnt.o: doprnt.c charset.h $(config_h)
*** 1119,1130
dosfns.o: buffer.h termchar.h termhooks.h frame.h blockinput.h window.h \
msdos.h dosfns.h dispextern.h charset.h coding.h $(config_h)
editfns.o: editfns.c window.h buffer.h systime.h $(INTERVAL_SRC) charset.h \
!coding.h dispextern.h frame.h $(config_h)
emacs.o: emacs.c commands.h systty.h syssignal.h blockinput.h process.h \
termhooks.h buffer.h atimer.h systime.h $(INTERVAL_SRC) $(config_h) \
window.h dispextern.h keyboard.h keymap.h
fileio.o: fileio.c window.h buffer.h systime.h $(INTERVAL_SRC) charset.h \
!coding.h msdos.h dispextern.h $(config_h)
filelock.o: filelock.c buffer.h charset.h coding.h systime.h epaths.h
$(config_h)
filemode.o: filemode.c $(config_h)
frame.o: frame.c xterm.h window.h frame.h termhooks.h commands.h keyboard.h \
--- 1119,1130
dosfns.o: buffer.h termchar.h termhooks.h frame.h blockinput.h window.h \
msdos.h dosfns.h dispextern.h charset.h coding.h $(config_h)
editfns.o: editfns.c window.h buffer.h systime.h $(INTERVAL_SRC) charset.h \
!coding.h dispextern.h frame.h blockinput.h $(config_h)
emacs.o: emacs.c commands.h systty.h syssignal.h blockinput.h process.h \
termhooks.h buffer.h atimer.h systime.h $(INTERVAL_SRC) $(config_h) \
window.h dispextern.h keyboard.h keymap.h
fileio.o: fileio.c window.h buffer.h systime.h $(INTERVAL_SRC) charset.h \
!coding.h msdos.h dispextern.h blockinput.h $(config_h)
filelock.o: filelock.c buffer.h charset.h coding.h systime.h epaths.h
$(config_h)
filemode.o: filemode.c $(config_h)
frame.o: frame.c xterm.h window.h frame.h termhooks.h commands.h keyboard.h \
Index: src/dired.c
===
RCS file: /cvsroot/emacs/emacs/src/dired.c,v
retrieving revision 1.123
diff -c -p -r1.123 dired.c
*** src/dired.c 24 Jun 2006 07:24:42 - 1.123
--- src/dired.c 8 Jul 2006 05:30:06 -
*** extern struct direct *readdir ();
*** 99,104
--- 99,105
#include charset.h
#include coding.h
#include regex.h
+ #include blockinput.h
/* Returns a search buffer, with a fastmap allocated and ready to go. */
extern struct re_pattern_buffer *compile_pattern ();
*** Elements of the attribute list are:
*** 951,960
--- 952,963
}
else
{
+ BLOCK_INPUT;
pw = (struct passwd *) getpwuid (s.st_uid);
values[2] = (pw ? build_string (pw-pw_name) : make_number (s.st_uid));
gr = (struct group *) getgrgid (s.st_gid);
values[3] = (gr ? build_string (gr-gr_name) : make_number (s.st_gid));
+ UNBLOCK_INPUT;
}
values[4] = make_time (s.st_atime);
values[5] = make_time (s.st_mtime);
Index: src/editfns.c
===
RCS file: /cvsroot/emacs/emacs/src/editfns.c,v
retrieving revision
Re: Reentrant call to malloc/free
On Wed, 05 Jul 2006 13:25:12 +0200, [EMAIL PROTECTED] (Dr. Carsten Bormann) said: While typing input (apparently often related to file/process operations, such as minibuffer completions of file names), emacs occasionally (say, once a day in heavy usage) hangs and uses high CPU (most of which is system time). Attaching GDB says: #11 0x000e0850 in poll_for_input () #12 0x00213930 in alarm_signal_handler () #13 signal handler called #14 0x90006a8c in szone_free () #15 0x0320 in ?? () #16 0x9005d7dc in getgr_internal () #17 0x9005d070 in getgr () #18 0x0013ed6c in Ffile_attributes () I've once posted a (not complete) list of Darwin library functions that may call malloc-related functions but are not protected by BLOCK_INPUT: localtime, gmtime, ctime, opendir, getc, getaddrinfo, fwrite, mkstemp fclose, closedir, freeaddrinfo, mktime (not used as of 2004-09) (http://lists.gnu.org/archive/html/emacs-devel/2004-09/msg00074.html) I cannot detect `getgrgid' as such a function, but I guess this is due to the difference in name service backends (NIS, LDAP, ...). We can put BLOCK_INPUTs around every getpw* and getgr* call, but if the problem only occurs on Darwin, creating wrapper functions is an alternative way. Does anyone know the situation on other systems? YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [EMAIL PROTECTED]: Overlay string not displayed on text with `display' property]
On Fri, 23 Jun 2006 16:43:33 +0200, [EMAIL PROTECTED] (Kim F. Storm) said: Redisplay state was not restored properly after a composition. I've fixed this by using the iterator stack for compositions. I don't find any display problems so far. Thanks. But an assertion violation occurs when displaying multibyte composite characters. (insert (compose-string ´e)) Actually, debugging these problems has given me a further level of knowledge about the redisplay engine internals, and I can see some possible simplifications (for after the release). That's a good news!! YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: ACL / Listener - Hang (Carbon port)
On Sun, 25 Jun 2006 17:46:39 +0100, David Reitter [EMAIL PROTECTED] said: Emacs hangs (no C-g possible) when create new listener from the Allegro Common Lisp package is selected - I can't verify / investigate further as I don't have Allegro Common Lisp. The package seems non-standard, but I don't see how an elisp package can legally bring Emacs to a halt (with C-g not working). It's not difficult to do so. ;; Can't quit with C-g. Send SIGFPE instead. (let ((inhibit-quit t)) (while t)) And the info entry for with-local-quit says there are several places where inhibit-quit is bound to t. This macro is mainly useful in functions that can be called from timers, process filters, process sentinels, `pre-command-hook', `post-command-hook', and other places where `inhibit-quit' is normally bound to `t'. I'm not sure this is the cause of the unresponsiveness, though. The version he is using is a patched GNU Emacs CVS derviate (CVS as of 2006-04-10), Carbon port, running on an Intel Mac with OS X. I don't believe any of the extensions to GNU Emacs present in his build can account for the hang this user is seeing. The next thing to do for debugging would be identifying situations/platforms where the problem occurs. * Identifying situations: - Try sending SIGFPE. Hopefully we get Lisp-level backtrace. - Try debugging with GDB using hints in etc/DEBUG. * Identifying platforms: - Try X11 version. - Try Carbon version without any modifications. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Random crashes
On Fri, 16 Jun 2006 18:34:08 -0500, Pablo Barros [EMAIL PROTECTED] said: Crashes randomly on MacOS X. Seems to be related to usage time; works fine right after installation, then gets unstable after around a week. I'm afraid the above information is not too useful for debugging. I think the Reporting Bugs section in Emacs info is good to read. In GNU Emacs 22.0.50.1 (powerpc-apple-darwin8.5.0) of 2006-03-22 on G5.local X server distributor `Apple Computers', version 10.4.6 configured using `configure '--prefix=/Applications/Emacs.app/ Contents/Resources' '--with-carbon' '--without-x' '--libexecdir=/ Volumes/Emacs/Emacs.app/Contents/MacOS/libexec' 'CFLAGS=-arch i386 - arch ppc -isysroot /Developer/SDKs/MacOSX10.4u.sdk -DUSE_ATSUI'' Are you using a distribution of precompiled Carbon Emacs? Then, please try the latest CVS if possible in order to rule out the possibility of: * The bug is already fixed (2006-03-22 is rather old.) * Some local changes in the distribution affect the unstableness. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [EMAIL PROTECTED]: Overlay string not displayed on text with `display' property]
On Fri, 16 Jun 2006 13:52:47 +0200, [EMAIL PROTECTED] (Kim F. Storm) said: Please continue testing!!! Yes, thanks. Here are two cases: * Case 1: The before-string is shown twice. ; emacs -Q -D (setq overlay (make-overlay 1 3)) (overlay-put overlay 'before-string (propertize BE 'face 'bold)) (overlay-put overlay 'after-string (propertize AF 'display (propertize XY 'face 'underline))) (put-text-property 1 3 'display (compose-string DISP)) * Case 2: Cursor at a wrong position. ; emacs -q -D ;; not `-Q' in order to show a message in *scratch* (setq overlay (make-overlay 1 3)) (overlay-put overlay 'before-string (propertize BEFORE_STRING 'face 'bold)) (overlay-put overlay 'after-string (propertize AF 'display (propertize XY 'face 'underline))) (put-text-property 1 3 'invisible t) ;; make sure that the first line is wrapped M- YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [EMAIL PROTECTED]: Overlay string not displayed on text with `display' property]
On Thu, 15 Jun 2006 16:45:01 +0200, [EMAIL PROTECTED] (Kim F. Storm) said: Please try the patch below. I tried it, and found a problem with cursor placement and another assertion violation. ; emacs -q -D ;; not `-Q' in order to show a message in *scratch* (setq overlay (make-overlay 1 3)) (overlay-put overlay 'before-string (propertize BE 'face 'bold)) (overlay-put overlay 'after-string (propertize AF 'display (propertize XY 'face 'underline))) (put-text-property 1 3 'display DISP) ;; make sure that the first line is wrapped M- Then the cursor is displayed at a wrong position. Another assertion violation can be observed by replacing the last expression with (put-text-property 1 3 'display '(space :width 2)) YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [EMAIL PROTECTED]: Overlay string not displayed on text with `display' property]
On Mon, 12 Jun 2006 11:26:07 +0200, [EMAIL PROTECTED] (Kim F. Storm) said: So it may be a question of specifically handling before-string and after-string properties at the boundaries of display and composition properties. Yes, that's exactly what I need. Maybe I've unconsciously oversimplified the issue. It seems to work fine With the following patch (not trivial, but not extremely complex either): Great! Thanks for working on this. There seems to be some problems with this patch. Besides an apparent typo (compute_stop_pos), some assertions are violated with the test case you mentioned: ; emacs -Q -D (setq overlay (make-overlay 1 3)) (overlay-put overlay 'before-string (propertize BE 'face 'bold)) (overlay-put overlay 'after-string (propertize AF 'display (propertize XY 'face 'underline))) (put-text-property 1 3 'display DISP) And crashed if the last one was changed to (put-text-property 2 3 'display DISP), though the case that overlay strings are not at boundaries of display property was not what I intended. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [EMAIL PROTECTED]: Overlay string not displayed on text with `display' property]
On Sun, 11 Jun 2006 12:06:51 +0200, [EMAIL PROTECTED] (Kim F. Storm) said: There may be _some_ overlay properties where it could make sense, e.g. before-string and after-string, but doing a lot of work just to make those work is not worth the trouble IMO. So I think we should simply document the current behaviour. I agree with you about not making nontrivial changes before the release. But I don't think that it is not worth the trouble in the long term. First, images are usually displayed using the `display' property, and overlay strings are not shown before them. Second, the `composition' property shows the similar behavior as I mentioned in http://lists.gnu.org/archive/html/emacs-devel/2006-06/msg00119.html. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Can't put cursor after wrapped overlay string with `cursor' property
On Mon, 29 May 2006 09:54:24 +0900, YAMAMOTO Mitsuharu [EMAIL PROTECTED] said: But now I see some strange behavior if the overlay is placed at the end of line. emacs -Q -D (setq overlay (make-overlay 1 1)) (setq str (make-string 100 ?a)) (overlay-put overlay 'before-string str) M- RET C-p -- The cursor at the previous position doesn't get erased. C-l -- The cursor is displayed at the vertical center position. The following change seems to work for me. Could someone check if this is correct? YAMAMOTO Mitsuharu [EMAIL PROTECTED] Index: src/xdisp.c === RCS file: /cvsroot/emacs/emacs/src/xdisp.c,v retrieving revision 1.1101 diff -c -r1.1101 xdisp.c *** src/xdisp.c 28 May 2006 20:19:07 - 1.1101 --- src/xdisp.c 2 Jun 2006 08:00:17 - *** *** 11777,11783 /* If we reached the end of the line, and end was from a string, cursor is not on this line. */ ! if (glyph == end) return 0; } --- 11779,11785 /* If we reached the end of the line, and end was from a string, cursor is not on this line. */ ! if (glyph == end row-continued_p) return 0; } ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Can't display help-echo in overlay string with composition.
On Wed, 31 May 2006 12:13:52 +0900 (JST), YAMAMOTO Mitsuharu [EMAIL PROTECTED] said: Arg out of range 0,0 repeatedly occurs when trying to display help-echo string in an overlay string with composition. 1. emacs -Q -D 2. (overlay-put (make-overlay 1 1) 'before-string (propertize (compose-string ab) 'help-echo ab)) 3. Move the mouse pointer to the beginning of buffer. The following change seems to work for me. Could someone check if this is correct? YAMAMOTO Mitsuharu [EMAIL PROTECTED] Index: src/xdisp.c === RCS file: /cvsroot/emacs/emacs/src/xdisp.c,v retrieving revision 1.1101 diff -c -r1.1101 xdisp.c *** src/xdisp.c 28 May 2006 20:19:07 - 1.1101 --- src/xdisp.c 2 Jun 2006 08:00:17 - *** *** 6238,6243 --- 6238,6245 it-position = (STRINGP (it-string) ? it-current.string_pos : it-current.pos); + if (STRINGP (it-string)) + it-object = it-string; return 1; } ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Can't display help-echo in overlay string with composition.
Arg out of range 0,0 repeatedly occurs when trying to display help-echo string in an overlay string with composition. 1. emacs -Q -D 2. (overlay-put (make-overlay 1 1) 'before-string (propertize (compose-string ab) 'help-echo ab)) 3. Move the mouse pointer to the beginning of buffer. YAMAMOTO Mitsuharu [EMAIL PROTECTED] In GNU Emacs 22.0.50.1 (sparc-sun-solaris2.8, X toolkit, Xaw3d scroll bars) of 2006-05-31 on church X server distributor `ATT Laboratories Cambridge', version 11.0.3332 configured using `configure '--x-libraries=/usr/local/lib' 'CFLAGS=-g -O2 -mv8 -DSYNC_INPUT'' 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: ja locale-coding-system: japanese-iso-8bit default-enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: 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 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Overlay string not displayed on text with `display' property
I'm not quite sure if this is a bug or not. Please tell me if it is not. An overlay string is not displayed if it is on (before?) the text that has some `display' property. For example, 1. emacs -Q -D 2. (setq overlay (make-overlay 1 1)) 3. (overlay-put overlay 'before-string aaa) Then aaa is displayed at the beginning of buffer. 4. (put-text-property 1 2 'display bbb) Then aaa disappears. YAMAMOTO Mitsuharu [EMAIL PROTECTED] 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 /opt/local/src/emacs/etc/DEBUG for instructions. In GNU Emacs 22.0.50.1 (sparc-sun-solaris2.8, X toolkit, Xaw3d scroll bars) of 2006-05-29 on church X server distributor `The XFree86 Project, Inc', version 11.0.4030 configured using `configure '--x-libraries=/usr/local/lib' 'CFLAGS=-g -O2 -mv8 -DSYNC_INPUT'' 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: ja locale-coding-system: japanese-iso-8bit default-enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: display-time-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 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: dump-emacs not working for me on Mac OS X
On Thu, 27 Apr 2006 12:49:24 -0700, Bill Clementson [EMAIL PROTECTED] said: I'm trying to do a dump-emacs (as described here: http://www.emacswiki.org/cgi-bin/wiki/DumpingEmacs) in order to reduce my startup times by preloading libraries that I always load in my .emacs file. However, I always get a segmentation fault. David Reitter, who produces the Aquamacs Emacs distribution for Mac OS X, also encountered the same problem and suggested that I send in a bug report (Note that the following is done with vanilla CVS emacs and not Aquamacs). It seems that unexmacosx.c does not allow us to dump with a dumped executable. I'll install a change so that it shows an error message when such an attempt is made. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Mode-line display bug in XFT_JHD_BRANCH
On Mon, 17 Apr 2006 13:09:16 +0530, Baishampayan Ghose [EMAIL
PROTECTED] said:
Hello, I am using the Emacs XFT_JHD_BRANCH and there is a weird
mode-line display bug in it. When the file has variable width fonts
like in LaTeX mode, the mode-line becomes garbled on scrolling. A
screen shot [0] is attached. I guess now that the XFT Unicode
branches have been merged, this critical bug will be fixed. I can
help with testing the branch by doing daily builds, if it's being
developed actively. Miles, what do you think about this? Regards,
BG
[0] http://people.ubuntu-in.org/~ghoseb/emacs_xft_mode-line_bug.png
I tried to make a small patch for some problems that don't require too
many changes to fix (or workaround). This is for XFT_JHD_BRANCH, not
for unicode-xft. I don't have a plan to work for Xft support, but I
simply ported some results from my previous ATSUI support on Mac to
Xft.
YAMAMOTO Mitsuharu
[EMAIL PROTECTED]
Index: src/xfaces.c
===
RCS file: /cvsroot/emacs/emacs/src/xfaces.c,v
retrieving revision 1.316.2.4
diff -c -r1.316.2.4 xfaces.c
*** src/xfaces.c12 Jan 2006 10:25:47 - 1.316.2.4
--- src/xfaces.c25 Apr 2006 07:37:07 -
***
*** 5282,5288
XQueryColors (FRAME_X_DISPLAY (f), FRAME_X_DISPLAY_INFO (f)-cmap,
colors, 2);
! face-xft_fg.color.alpha = face-xft_fg.color.alpha = 0x;
face-xft_fg.color.red = colors[0].red;
face-xft_fg.color.green = colors[0].green;
face-xft_fg.color.blue = colors[0].blue;
--- 5282,5288
XQueryColors (FRAME_X_DISPLAY (f), FRAME_X_DISPLAY_INFO (f)-cmap,
colors, 2);
! face-xft_fg.color.alpha = face-xft_bg.color.alpha = 0x;
face-xft_fg.color.red = colors[0].red;
face-xft_fg.color.green = colors[0].green;
face-xft_fg.color.blue = colors[0].blue;
***
*** 7243,7248
--- 7243,7251
{
bcopy (base_face, face, sizeof *face);
face-gc = 0;
+ #ifdef HAVE_XFT
+ face-xft_draw = NULL;
+ #endif
/* Don't try to free the colors copied bitwise from BASE_FACE. */
face-colors_copied_bitwise_p = 1;
Index: src/xterm.c
===
RCS file: /cvsroot/emacs/emacs/src/xterm.c,v
retrieving revision 1.861.2.4
diff -c -r1.861.2.4 xterm.c
*** src/xterm.c 12 Jan 2006 10:25:47 - 1.861.2.4
--- src/xterm.c 25 Apr 2006 07:37:08 -
***
*** 1202,1210
x_set_glyph_string_clipping (s)
struct glyph_string *s;
{
! XRectangle r;
! get_glyph_string_clip_rect (s, r);
! XSetClipRectangles (s-display, s-gc, 0, 0, r, 1, Unsorted);
}
--- 1202,1216
x_set_glyph_string_clipping (s)
struct glyph_string *s;
{
! #define MAX_CLIP_RECTS 2
! XRectangle r[MAX_CLIP_RECTS];
! int n;
!
! n = get_glyph_string_clip_rects (s, r, MAX_CLIP_RECTS);
! XSetClipRectangles (s-display, s-gc, 0, 0, r, n, Unsorted);
! #ifdef HAVE_XFT
! XftDrawSetClipRectangles (s-face-xft_draw, 0, 0, r, n);
! #endif
}
***
*** 1382,1392
strlen (weight_name) +
strlen (slant_name) +
5 + /* pixel */
! 9 + /* stars */
14 + /* dashes */
1); /* null */
xlfd = malloc (len);
! sprintf(xlfd, -%s-%s-%s-%s-*-*-%d-*-*-*-*-0-*-*,
foundry, family, weight_name, slant_name,
(int) (pixel + 0.5));
return xlfd;
--- 1388,1398
strlen (weight_name) +
strlen (slant_name) +
5 + /* pixel */
! 6 + 1 + 8 + 1 + /* stars, 0, iso10646, 1 */
14 + /* dashes */
1); /* null */
xlfd = malloc (len);
! sprintf(xlfd, -%s-%s-%s-%s-*-*-%d-*-*-*-*-0-iso10646-1,
foundry, family, weight_name, slant_name,
(int) (pixel + 0.5));
return xlfd;
***
*** 1551,1589
use XDrawImageString when drawing the cursor so that there is
no chance that characters under a box cursor are invisible. */
#ifdef HAVE_XFT
! /* KOKO: Always clear background for now, there are some redraw problems
! otherwise. */
! if (1 || ! (s-for_overlaps
! || (s-background_filled_p s-hl != DRAW_CURSOR)))
! XftDrawRect (s-face-xft_draw,
! s-hl == DRAW_CURSOR ? s-face-xft_fg :
s-face-xft_bg,
! s-x,
! s-y,
! s-width + s-right_overhang,
! s-height);
! if (s-two_byte_p)
! {
! XftChar16 ch[s-nchars];
! int
Re: Strange display behavior after filling
On Tue, 18 Apr 2006 13:57:46 +0200, [EMAIL PROTECTED] (Kim F. Storm) said: Please test if this gives good results, or if it has some bad effects on existing features I tried the patch, and I found another case that shows a similar problem: 1. emacs -D -q (not -Q to show the message in *scratch*) 2. M-q 3. M- C-e C-d C-e C-d Then the message ;; This buffer ... own buffer. is shown in one line. 4. M- C-u 1 C-v 5. M-q 6. C-p C-n C-n The examples I've shown may look artificial, but I sometimes experience some redisplay glitches such as violation of the assertion IT_BYTEPOS (*it) == CHAR_TO_BYTE (IT_CHARPOS (*it)) in set_iterator_to_next, or partial octal representation of a multibyte character after fill operations. (The buffer contents seems to be correct because C-l fixes redisplay in these cases.) So I was trying to find reliably reproducible cases. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Strange display behavior after filling
I found some strange display behavior after filling. In the following, row means a displayed horizontal segment, and line means a sequence of characters delimited by newlines. 1. emacs -D -Q 2. M-q (I'm not sure why this is needed.) 3. Insert 123456789 (without quotations or newlines) 18 times. Say, C-x ( 1 2 3 4 5 6 7 8 9 SPC C-x ) C-u 1 7 C-x e. It is displayed in three rows. 4. M- 5. C-u 1 C-v Now the first row becomes continued to both directions. 6. M-q Then the first row is displayed shorter than the second one, whereas they have the same number of characters. 7. C-p C-n C-n The line number in the mode line says the cursor is at the third line. But it is displayed at the second row that corresponds to the second line. YAMAMOTO Mitsuharu [EMAIL PROTECTED] In GNU Emacs 22.0.50.1 (sparc-sun-solaris2.8, X toolkit, Xaw3d scroll bars) of 2006-04-11 on church X server distributor `The XFree86 Project, Inc', version 11.0.4030 configured using `configure '--x-libraries=/usr/local/lib' 'CFLAGS=-g -O2 -mv8 -DSYNC_INPUT'' 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: ja locale-coding-system: japanese-iso-8bit default-enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t auto-compression-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 line-number-mode: t ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: crash in xdisp.c: show_mouse_face
On Sat, 1 Apr 2006 00:41:29 +0100, David Reitter [EMAIL PROTECTED] said:
A user reported a crash under the circumstances described below.
This is the Carbon port of GNU Emacs from March 28, with some
patches (none to xdisp.c). Please see the stack trace below, and
ask Phil directly in case there are questions - I don't have more
information.
I'm not sure if it is related, but the following change seems to have
introduced the use of the uninitialized variable `f'.
2006-03-24 Kim F. Storm [EMAIL PROTECTED]
* macterm.c (XTread_socket): Don't let key-press clear mouse face
on in toolbar window if mouse-highlight is an integer.
I've installed the following fix to the CVS. Please try it. Phil, do
you possibly set the variable `mouse-highlight' to some integer?
YAMAMOTO Mitsuharu
[EMAIL PROTECTED]
===
RCS file: /sources/emacs/emacs/src/macterm.c,v
retrieving revision 1.162
retrieving revision 1.163
diff -c -r1.162 -r1.163
*** emacs/src/macterm.c 2006/03/24 15:22:44 1.162
--- emacs/src/macterm.c 2006/04/03 06:28:39 1.163
***
*** 10455,10460
--- 10455,10462
ObscureCursor ();
+ f = mac_focus_frame (dpyinfo);
+
if (!dpyinfo-mouse_face_hidden INTEGERP (Vmouse_highlight)
!EQ (f-tool_bar_window, dpyinfo-mouse_face_window))
{
***
*** 10500,10506
inev.modifiers |= (extra_keyboard_modifiers
(meta_modifier | alt_modifier
| hyper_modifier | super_modifier));
! XSETFRAME (inev.frame_or_window, mac_focus_frame (dpyinfo));
break;
case kHighLevelEvent:
--- 10502,10508
inev.modifiers |= (extra_keyboard_modifiers
(meta_modifier | alt_modifier
| hyper_modifier | super_modifier));
! XSETFRAME (inev.frame_or_window, f);
break;
case kHighLevelEvent:
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Carbon: mac-pass-command-to-system disfunctional
On Fri, 31 Mar 2006 09:10:59 +0100, David Reitter [EMAIL PROTECTED] said: Seems like mac-pass-command-to-system is broken. Testcase: (setq mac-pass-command-to-system nil) Press Command-h. You should get a A-h is undefined message (or similar). I tried the testcase with the Carbon port, but I got this error provided I've set `mac-command-modifier' to `alt'. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Carbon / tool-bar: changes in size temporarily
On Fri, 31 Mar 2006 09:19:01 +0100, David Reitter [EMAIL PROTECTED] said: In the Carbon port, when a large font (e.g. Monaco 18) is selected for a frame, the tool-bar becomes (visually) much higher (I guess 3 lines high). However, when you toggle the visibility of the tool-bar, for example with the following code (modify-frame-parameters nil '((tool-bar-lines . 0))) (modify-frame-parameters nil '((tool-bar-lines . 1))) the tool-bar shrinks back to a visually much more appealing height - that is, about 2 lines high. I could reproduce it also with the X11 (non-GTK) build by changing the frame font to Courier 24 by S-mouse-1, followed by the evaluation of the above expressions. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Carbon port: Russian language selected
On Wed, 29 Mar 2006 19:27:06 +0100, David Reitter [EMAIL PROTECTED] said: Does anyone know what this could be? I can't reproduce it myself, but a user reported an immediate exit upon startup with an output (presumably to stdout) Invalid coding system: mac-cyrillic. System Preferences-International-Language has Russian (in cyrillic) on top, i.e. as preferred language. I could reproduce it and just installed a fix. Thanks for the report. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Menu bar is skrewed up when using filesets
On Mon, 20 Mar 2006 14:44:52 +0100, Martin Buchmann [EMAIL PROTECTED] said: After I erased all of the customization for the filesets section and the ~/.filesets-cache.el file, filesets are working fine again. Nevertheless, I don't understand how a corrupted cache file or a wrong customization could lead to this behaviour. Then it seems to be difficult for us to know what was wrong without your customization and the cache file. If you feel uncomfortable to make them public by sending them to the list, can you send them to me directly? YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Menu bar is skrewed up when using filesets
On Mon, 20 Mar 2006 09:51:53 +0100, Martin Buchmann [EMAIL PROTECTED] said: If I want to use filesets and add (filesets-init) to my init file (~/.emacs.d/init.el) as suggested in the Emacs manual, the menu bar contains only the emacs and the fileset menu. All other menus (File, Edit, etc.) are missing. I could not reproduce it, but could you test if the following patch makes some difference on your side? YAMAMOTO Mitsuharu [EMAIL PROTECTED] Index: src/macmenu.c === RCS file: /cvsroot/emacs/emacs/src/macmenu.c,v retrieving revision 1.38 diff -c -r1.38 macmenu.c *** src/macmenu.c 22 Feb 2006 07:59:34 - 1.38 --- src/macmenu.c 20 Mar 2006 09:37:46 - *** *** 63,71 #include dispextern.h #define POPUP_SUBMENU_ID 235 ! #define MIN_POPUP_SUBMENU_ID 512 ! #define MIN_MENU_ID 256 ! #define MIN_SUBMENU_ID 1 #define DIALOG_WINDOW_RESOURCE 130 --- 63,71 #include dispextern.h #define POPUP_SUBMENU_ID 235 ! #define MIN_POPUP_SUBMENU_ID 4096 ! #define MIN_MENU_ID 1 ! #define MIN_SUBMENU_ID 256 #define DIALOG_WINDOW_RESOURCE 130 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Slider draw bug in Carbon port
On Sat, 4 Mar 2006 15:56:50 +, David Reitter [EMAIL PROTECTED] said: The bug that causes the slider to be drawn in a wrong position is still present. I've reported this earlier. It's hard to say when exactly it occurs, but I see it fairly often. It usually goes away after a redraw. It can be reproduced with the following procedure: 1) Emacs -Q 2) C-x 2 3) Drag the upper mode line downward until the number of lines of the lower window becomes 3. 4) M-x C-q C-j Carbon scroll bars seem to behave strangely (i.e., display garbage outside the control rectangle) when it is too short. At least, scroll bars in Mac OS X 10.3.9 and 10.4.5 behave differently in such cases. I suspect that this is a bug in Carbon, but anyway, I installed some workaround because we cannot expect that it will be fixed for old versions. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Carbon crashes in mac_handle_mouse_event
On Tue, 7 Mar 2006 16:40:25 +, David Reitter [EMAIL PROTECTED] said: A user reported crashes, consistently in mac_handle_mouse_event. Could you see whether the following change that I've just made the other day works? 2006-03-06 YAMAMOTO Mitsuharu [EMAIL PROTECTED] * macterm.c: [USE_CARBON_EVENTS] (mac_convert_event_ref) (mac_handle_command_event, mac_handle_window_event) (mac_handle_mouse_event): Check error code of GetEventParameter. (convert_fn_keycode) [MAC_OSX]: Likewise. This was intended for the prolem that Carbon Emacs crashes if mouse wheel is moved at startup. So it was not directly for the one you described, but it seems to happen at the same place of the code. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Problems with international characters in menus on Mac OSX
On Mon, 06 Mar 2006 11:55:44 +0900, Kenichi Handa [EMAIL PROTECTED] said: In article [EMAIL PROTECTED], John Olsson [EMAIL PROTECTED] writes: If I add a menu to the menu bar (or menu items to a menu) containing international characters (for instance any of the swedish characters 'å', 'ä' and 'ö') they will not show up correctly. For instance 'å' shows as  'ä' shows as '‰' 'ö' shows as '^' 'Å' shows as '≈' [...] In GNU Emacs 22.0.50.1 (powerpc-apple-darwin7.9.0) of 2005-09-28 on lucy - Aquamacs Distribution 0.9.6 It seems that this is a problem specific to powerpc-apple-darwin7.9.0. On GNU/Linux with X Window System, for instance, the following code works well; i.e. clicking Test in menu bar shows å ä ö Å correctly (in latin-1 language environment). (define-key global-map [menu-bar test] (cons Test test-menu)) (Test keymap Test) (define-key test-menu [test-insert] '(menu-item å ä ö Å (lambda () (interactive) (insert å ä ö Å It also works on Mac OS X/Carbon. (I suppose you have (setq test-menu (make-sparse-keymap Test)) before the first expression.) Maybe specific to Aquamacs 0.9.6? YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Carbon: display-buffer can leave wrong frame with input focus
On Thu, 9 Feb 2006 08:58:10 +, David Reitter [EMAIL PROTECTED] said: Works as intended. The fact that newly opened frames get the focus seems inconsistent, however. From a user's perspective, the same sequence of inputs will not lead to the same results, depending on whether the other frame happens to get focus or not. I think it'd be better if the newly opened frame never gets focus - even if the window manager initially gives it focus. That would implement the documentation of display-buffer more closely: Make buffer appear in some window but don't select it. Anyway, that's no longer a Carbon-specific issue. All X11 window managers that I regularly use behave like this (i.e., a new frame created by make-frame will get focus). At least, you can customize the behavior so as not to change the focus like this: (defun my-special-display-popup-frame (buffer optional args) (let ((orig-frame (selected-frame))) (special-display-popup-frame buffer args) (x-focus-frame orig-frame))) (setq special-display-function 'my-special-display-popup-frame) YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash during access_keymap
On Thu, 29 Dec 2005 12:11:07 -0500, Richard M. Stallman [EMAIL PROTECTED] said: I think I fixed the problem of pure objects pointing to impure ones that might get reclaimed. Do you think the problem is fixed? Yes. As for international/encoded-kb, preloading it now reports the Attempt to modify read-only object error. So I think it is no longer tried to be preloaded. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash during access_keymap
On Wed, 16 Nov 2005 17:01:35 -0500, Richard M. Stallman [EMAIL
PROTECTED] said:
Meanwhile, how about this fix in keymap.c?
This correctly reports an error for the international/encoded-kb case,
but I think at least the vector case in store_in_keymap still has a
missing CHECK_IMPURE.
if (VECTORP (elt))
{
if (NATNUMP (idx) XFASTINT (idx) ASIZE (elt))
{
ASET (elt, XFASTINT (idx), def);
return def;
}
insertion_point = tail;
}
YAMAMOTO Mitsuharu
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash during access_keymap
On Tue, 15 Nov 2005 18:21:59 -0500, Richard M. Stallman [EMAIL PROTECTED] said: I meant a kind of analysis to ensure that any literals inside a function are not modified. I don't quite follow. If they are pure, they cannot be modified; the primitives that would do so will signal an error. Unless they have bugs. I'm not suggesting anything. You say compile-time check is unnecessary. I say it is difficult. No problem. On a system where pure space really is read-only, trying to modify it would cause an immediate crash--good for debugging, but not an elegant way to report the problem. I guess there are many places that don't do CHECK_IMPURE, and setting watchpoint is as useful for debugging as the read-only pure space. Actually, I found another problem related to international/encode-kb.el using it. This causes a real problem unlike the Fccl_execute_on_string case. (defconst encoded-kbd-mode-map (make-sparse-keymap) Keymap for Encoded-kbd minor mode.) The keymap is allocated in the pure storage if this file is preloaded, because it is defined by `defconst' (should be `defvar'?). But it is modified in the following part. (defun encoded-kbd-setup-keymap (coding) ;; At first, reset the keymap. (define-key encoded-kbd-mode-map \e nil) ;; Then setup the keymap according to the keyboard coding system. `define-key' does not do CHECK_IMPURE for the given keymap, and the following situation really occurs. On Sun, 13 Nov 2005 15:39:37 +0900, YAMAMOTO Mitsuharu [EMAIL PROTECTED] said: So, if there's a non-pure object that is only pointed to by pure objects, which may happen if the assumption for the pure storage is violated, then the object is reachable but get collected. Now I'm sure this is the real cause of Wrong type argument: commandp error that is found in some Carbon Emacs distributions that preloads international/encoded-kb.elc. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash during access_keymap
On Mon, 14 Nov 2005 10:49:03 +0100, [EMAIL PROTECTED] (Kim F. Storm) said: It seems to be possible to have a check_pure_storage function which would traverse pure storage and validate that it only refers to other pure object -- and also that pure storage only contains valid objects (e.g. I don't think storing a buffer or window object in pure storage makes any sense). This function only needed to be run once during the build process, e.g. just before undump. Yeah, I only thought about the case that a pointer in the pure storage are changed so as to point to an impure object during the execution of a dumped one, but that may also occur in a dumping session. The latter cannot be caught by the watchpoint. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Carbon with -nw: kCGErrorRangeCheck / Abort trap
On Mon, 14 Nov 2005 12:14:39 +, David Reitter [EMAIL PROTECTED] said: The Carbon port starts up in TTY mode when given the -nw parameter. When logged in as non-console user, i.e. remotely, the process crashes. To reproduce: ssh [EMAIL PROTECTED] (...) lucy:/Volumes/Sista/Applications/Emacs.app/Contents/MacOS test$ ./Emacs -nw kCGErrorRangeCheck : Window Server communications from outside of session allowed for root and console user only INIT_Processeses(), could not establish the default connection to the WindowServer. Fatal error (6)Abort trap Thanks for the report. I just installed a fix. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash during access_keymap
On Tue, 15 Nov 2005 00:42:57 -0500, Richard M. Stallman [EMAIL PROTECTED] said: If the problem is reproducible, it should be fairly straightforward to debug. Is there clobbered data or not? I myself don't see the problem, but according to the report from David, some keymap seems to be clobbered. I think compile-time analysis would not become perfect because of dynamic bindings. Sorry, I don't understand. Symbols are never copied to pure space, so their bindings, whether dynamic or not, can't cause this kind of problem. I meant a kind of analysis to ensure that any literals inside a function are not modified. In dynamic scoping environment, objects exposed to another function are not limited to those are passed via arguments. On some systems including Mac OS X, the pure storage is not remapped to the text segment. But still one can set watchpoint to the array `pure' to do run-time check. I don't follow. Run-time check of what? To detect the case that the contents of the pure storage are changed accidentally. It actually occurred when I tried preloading international/encoded-kb.elc. Maybe CHECK_IMPURE should be added to Fccl_execute_on_string? YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash during access_keymap
On Sun, 13 Nov 2005 19:24:34 +, David Reitter [EMAIL PROTECTED] said: On 13 Nov 2005, at 06:39, YAMAMOTO Mitsuharu wrote: So, if there's a non-pure object that is only pointed to by pure objects, which may happen if the assumption for the pure storage is violated, then the object is reachable but get collected. OK, that makes sense. Do you know if this is documented somewhere? I'm not sure if it is explicitly documented. I just read src/alloc.c. The function `mark_object' immediately returns if its argument is a pure object. I've read the info nodes about pure storage etc., and it doesn't say anything about what to look for in code, or if there is a way to test for the effect while loading. Maybe on a port that implements memory protection? Setting watchpoint to the variable `pure' will do run-time check. It is really feasible in GDB on Mac OS X thanks to hardware watchpoints. I mostly just preload code, but define a setup function in each package that is run at runtime. But from what you are saying, I am getting that vectors are allocated when the file is loaded, and not copied when a function is called. But if the code used (vector 0 0 0 0 0) instead of [0 0 0 0 0], the vector would be allocated at runtime and we don't run into such trouble. Yes, but a vector is created on every call then. Does this apply only to vectors? (Since vectors seem immutable to me, this all would make sense...) Literal strings and conses, as well as several vector-like objects. I don't understand what vectors seem immutable means above. Vectors are mutable in the sense that one can alter their contents. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash during access_keymap
On Sat, 12 Nov 2005 11:35:43 +, David Reitter [EMAIL PROTECTED] said: Looking at the C-level patches that Aquamacs and Carbon Emacs Package have in common: - transparency - toolbar-button Both patches don't do anything unless their respective functionality is used, as far as I can tell. Either of them is not an essential feature, so you can try to test without them if needed. I suspect it's rather due to the higher memory management requirements - the distributions load more packages. I found both of the distributions have some entries for additional preloading in site-load.el, but some of them are not valid. For example, international/encoded-kb.el has the following code: (defun encoded-kbd-self-insert-ccl (ignore) (let ((str (char-to-string (encoded-kbd-last-key))) (ccl (car (aref (coding-system-spec (keyboard-coding-system)) 4))) (vec [nil nil nil nil nil nil nil nil nil]) result) (while (= (length (setq result (ccl-execute-on-string ccl vec str t))) 0) (dotimes (i 9) (aset vec i nil)) (setq str (format %s%c str (read-char-exclusive (vector (aref result 0 The vector [nil ...] is allocated in the pure storage if this file is preloaded, but its contents are altered in the function body and thus the read-only assumption of the pure storage is violated. So this file should not be preloaded as it is. Inappropriate preloading also affects the correctness of GC. Since the pure storage is assumed to be read-only, GC does not mark or follow the objects in this storage. So, if there's an object that is only pointed to by pure storage objects, which may happen if the assumption for the pure storage is violated, the object is reachable but never get collected. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash during access_keymap
On Sun, 13 Nov 2005 13:15:01 +0900, YAMAMOTO Mitsuharu [EMAIL PROTECTED] said: Inappropriate preloading also affects the correctness of GC. Since the pure storage is assumed to be read-only, GC does not mark or follow the objects in this storage. So, if there's an object that is only pointed to by pure storage objects, which may happen if the assumption for the pure storage is violated, the object is reachable but never get collected. The last sentence was not correct. It should have been: So, if there's a non-pure object that is only pointed to by pure objects, which may happen if the assumption for the pure storage is violated, then the object is reachable but get collected. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Carbon / reported font width wrong?
On Fri, 11 Nov 2005 15:50:14 +, David Reitter [EMAIL PROTECTED]
said:
In the Carbon port (current CVS), fontset-info or frame-char-width
report wrong pixel widths for fonts. In the example below, two
fontsets are created. The I set the frame font (to load the font)
and compare reported character width with (frame-char-width).
From my understanding of the documentation, the two should be the
same - but they differ.
They are not necessarily the same: the former is the maximum width,
and the latter is the average width.
The reason why they are not the same even in a fixed-width font is
that the maximum metrics are confused by characters missing in the
font. One way to avoid this is to define maximum/minimum metrics as
those among ASCII characters. This is what ATSUI support code is
doing.
YAMAMOTO Mitsuharu
[EMAIL PROTECTED]
Index: src/macterm.c
===
RCS file: /cvsroot/emacs/emacs/src/macterm.c,v
retrieving revision 1.142
diff -c -r1.142 macterm.c
*** src/macterm.c 11 Nov 2005 16:33:44 - 1.142
--- src/macterm.c 12 Nov 2005 05:31:57 -
***
*** 7572,7577
--- 7572,7584
SetRect (max_bounds, 0, 0, 0, 0);
for (c = 0x20; c = 0xff; c++)
{
+ if (c == 0x7f)
+ {
+ STORE_XCHARSTRUCT (font-min_bounds, min_width, min_bounds);
+ STORE_XCHARSTRUCT (font-max_bounds, max_width, max_bounds);
+ continue;
+ }
+
ch = c;
char_width = CharWidth (ch);
QDTextBounds (1, ch, char_bounds);
***
*** 7594,7601
UnionRect (max_bounds, char_bounds, max_bounds);
}
}
- STORE_XCHARSTRUCT (font-min_bounds, min_width, min_bounds);
- STORE_XCHARSTRUCT (font-max_bounds, max_width, max_bounds);
if (min_width == max_width
max_bounds.left = 0 max_bounds.right = max_width)
{
--- 7601,7606
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: OS X: Character Palette input doesn't work
On Thu, 10 Nov 2005 21:41:20 +, David Reitter [EMAIL PROTECTED] said: In the Carbon port, one cannot use the Character Palette to input characters into Emacs. The original report came from an Aquamacs user. It's easy to insert a Unicode character in a window from a Keyboard Viewer (e.g. a cyrillic character from an Ukrainian keyboard) but I cannot insert a Unicode character from the Character Palette. The Insert button remains grayed out. I confirmed this for a very recent Emacs CVS version. The Insert function of Character Palette is disabled while in Emacs. All other applications are happy to take input from it. This is documented in the Emacs info (the Keyboard and Mouse Input on Mac section): Emacs recognizes the setting in the Keyboard control panel (Mac OS Classic) or the International system preference pane (Mac OS X) and supports international and alternative keyboard layouts (e.g., Dvorak) if its script is either Roman, Japanese, Traditional Chinese, Korean, Cyrillic, Simplified Chinese, or Central European. Keyboard layouts based on Unicode may not work properly. Selecting one of the layouts from the keyboard layout pull-down menu will affect how the keys typed on the keyboard are interpreted. I couldn't find out what the cause of the problem is - I was looking for issues with the Carbon event handling and a missing event handler for some text input event. You may want to look at the following documents: Understanding Text Input and the Text Services Manager in Carbon http://developer.apple.com/documentation/Carbon/Conceptual/UnderstandTextInput_TSM/index.html Supporting Unicode Input http://developer.apple.com/documentation/Carbon/Conceptual/Supporting_Unicode_Input/index.html YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash during access_keymap
On Tue, 8 Nov 2005 00:57:19 +, David Reitter [EMAIL PROTECTED] said: If this is the same bug with corruption of keymaps that everybody is complaining about: please please findfix it. This occurs not only in Aquamacs, but also in recent Carbon Emacs Package builds. I've already spent hours on tracing this and finding a workaround, and I haven't gotten far with this. Thanks. Still I can't see the commandp problem with the CVS version. If it only occurs on some distributions of modified Carbon Emacs, it is difficult for me to help directly, sorry. One thing I can think of is heap corruption caused by missing BLOCK_INPUTs. If -DSYNC_INPUT suppresses the error, it might be due to this. (See the thread starting from http://lists.gnu.org/archive/html/emacs-devel/2004-09/msg00074.html) YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
