Re: Added text makes `C-h b' wider than 70 chars
This should take a step towards solving it.
*** keymap.c11 Feb 2006 11:43:58 -0500 1.318
--- keymap.c05 Mar 2006 16:02:47 -0500
***
*** 3371,3377
if (vect[i].shadowed)
{
SET_PT (PT - 1);
! insert_string (" (binding currently shadowed)");
SET_PT (PT + 1);
}
}
--- 3371,3377
if (vect[i].shadowed)
{
SET_PT (PT - 1);
! insert_string (" (shadowed)");
SET_PT (PT + 1);
}
}
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Options menu names
> From: "Drew Adams" <[EMAIL PROTECTED]> > Date: Sun, 5 Mar 2006 14:51:34 -0800 > > The issue is largely moot because there is no "Syntax Highlighting" > entry in the Option menu since it was removed on 2005-11-14 after > `global-font-lock-mode' had been turned on by default. > > Sigh. Please read the original bug report. Syntax Highlighting was one of > nine such menu items mentioned. Drew, would you please stop badgering people like that? The fact that they disagree or refer to the parts that are unimportant to you doesn't mean their read abilities are deficient. > My point was to use a verb phrase, not a noun phrase, for a toggle menu > item: "Drink Coca-Cola", not "Coca-Cola" (to use a recognizable name). Please look around at other GUI programs' Options menus, and see what language they use for the items there. I did that, and I cannot say they use verb phrases as a general principle. ___ 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: wrong frame is current when after-make-frame-functions
Sorry - just to clarify: Do you mean that the original frame, not the new frame, is selected when after-make-frame-functions is executed? If so, why is that correct? If it is correct, how can the user select the new frame (say in after-make-frame-functions) to do something to or in it - how can the new frame be addressed (what is its identity)? The new frame is the argument to each of the hook functions. Therefore, it is useful that the selected frame is unchanged. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Options menu names
Parallel structure would be a plus, but some of these rewordings are very strained, such as Case-Insensitive Search -> Search Case-Insensitively This is also unclear Completion for Query Replace -> Complete Query-Replace Input I think the minuses of this change outweigh the plus. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Options menu names
I said: If "Highlight Syntactically" and "Highlight Syntax" are not clear, and "syntax highlighting" is a well-recognized name, then the menu item should be called "Toggle Syntax Highlighting". It should not be called "Syntax Highlighting". FTR - My bad. "Toggle " would make sense if there were no indicator of the current state as part of the menu item. Since we use the presence or absence of a check mark to indicate the state, I should have suggested "Use Syntax Highlighting", which says what the item means in the checked state. As was pointed out, this particular item is no longer present, but the example still serves. "Use" is however a weak verb; it relies on the clarity of the noun that follows, such as "Syntax Highlighting". If foo is not clear, then neither is "use foo". Strong, active verbs are generally clearer than weak verbs because they are more specific - "highlight" is more specific than "use". "Use Foo"'s advantage over "Foo" is that it is consistent with other items (parallel construction). "Use" can be used when the wording might be strained with a stronger verb. Thus: "Use Case-Insensitive Search", "Use Completion for Query-Replace". With a noun phrase there is no indication of what the action is. For instance, "Syntax Highlighting" could be about defining syntax highlighting (choose what colors to use...). Some languages typically use a noun phrase where a verb phrase might be used in English. French, for instance, might use "Modification" where English would use "Edit". Verbs drive English - "you can verb any noun" is not just a catch phrase. Admittedly, if a check mark is present, then the toggle nature becomes clear: although "Syntax Highlighting" is unclear, "[X] Syntax Highlighting" is clear. Since not all items in the Options menu are toggles, however, the unchecked state is ambiguous - you must try the item to find out what it means. Given that we use a check mark to indicate the state, the main argument in favor of verb phrases is that parallel structure is easier to read: each item is implicitly introduced with the same contextual meaning - "click me to..." (use syntax highlighting, highlight matching parens,...). This is an argument for consistency, and, no, consistency is not an end in itself. Sometimes it is clearer to be inconsistent. The point is not to insert "Use" everywhere to render things 100% parallel. The point is to be aware of an inconsistency and be sure it is the best choice in context. If half the items in a menu use verb phrases and half use noun phrases, then it is likely that some of the noun phrases could profitably be turned into verb phrases. Likely, but not sure. And people can disagree about the details - whether a particular item is clearer than another. Other things being equal (that's an "if"), consistency helps. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs-unicode-2: copy & paste problem of non standard encoding ctext
In article <[EMAIL PROTECTED]>, Zhang Wei <[EMAIL PROTECTED]> writes: > The crxvt-gb that I installed comes from the "rxvt-ml" debian package. > $ crxvt-gb -help > Usage v2.6.4 : (XPM,utmp,menubar,Chinese (GB),graphics,XGetDefaults) I see. I've just installed it too, and found what's going on with them. I've just installed fixes. Could you please try again? The locale of Emacs and crxvt-gb must be the same. Then both ways of cut&paste should work well now in zh_CN.GB and in zh_CN.GBK. --- Kenichi Handa [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mouse-2 on menu item yanks into current buffer
Drew Adams wrote: I can't reproduce this on either 21.4 or CVS from 1 March on Windows XP. It must have been fixed then. Well, no, since I can't reproduce it in 21.4 either, which indicates that it hasn't ever been a problem in the Emacs 22 code. Either I misunderstood your report, or this is specific to your setup somehow. Here are the steps I used: 1) emacs -q --no-site-file 2) (setq w32-swap-mouse-buttons t) ; to make mouse-2 accessible on my 2 button mouse 3) type some text in the scratch buffer and select it with the mouse. 4) Open a menu with the mouse and right click one of the menu items. 5a) Click on the menu normally to select an item and close the menu. b) Repeat step 4 and click outside the menu to cancel it without selecting an item. No text was inserted in the scratch buffer by either these tests. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: mouse-2 on menu item yanks into current buffer
> I can't reproduce this on either 21.4 or CVS from 1 March > on Windows XP. > > It must have been fixed then. Well, no, since I can't reproduce it in 21.4 either, which indicates that it hasn't ever been a problem in the Emacs 22 code. Either I misunderstood your report, or this is specific to your setup somehow. Here are the steps I used: 1) emacs -q --no-site-file 2) (setq w32-swap-mouse-buttons t) ; to make mouse-2 accessible on my 2 button mouse 3) type some text in the scratch buffer and select it with the mouse. 4) Open a menu with the mouse and right click one of the menu items. 5a) Click on the menu normally to select an item and close the menu. b) Repeat step 4 and click outside the menu to cancel it without selecting an item. No text was inserted in the scratch buffer by either these tests. I have a 3-button mouse (the one I'm testing with now is actually a 5-button MS Intellimouse Explorer). If I repeat your recipe, so that I can use mouse-3 to simulate mouse-2, then the bug does not arise. However, if I repeat the recipe I sent (really use mouse-2; that is, without swapping buttons), then the bug arises systematically. IIUC, your test does not reproduce what I reported (neither the test nor the result). The conclusion is not that what I see is necessarily specific to my setup (also emacs -q --no-site-file, BTW). It's possible that simulating a 3-button mouse with a 2-button mouse does not manifest the bug. IOW, it would be good to test the recipe I sent, with a 3-button mouse, to see if the problem is not specific to my setup. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Options menu names
> All that you did was to argue by appealing to authority: some unnamed, > undescribed "widespread conventions that users expect." That's an empty > argument/explanation without saying what that authority is: > what conventions are you referring to? What user-expecting convention > does "Syntax Highlighting" follow? The issue is largely moot because there is no "Syntax Highlighting" entry in the Option menu since it was removed on 2005-11-14 after `global-font-lock-mode' had been turned on by default. Sigh. Please read the original bug report. Syntax Highlighting was one of nine such menu items mentioned. Eli referenced it (not I) as an example of one those items that respects a different (unspoken) convention. I don't know which other item names he was also justifying this way; he said only "some of the menu items, such as Syntax Highlighting". I don't know what convention he was referring to, only that is is widespread and expected by users. FWIW, I agree with Eli. I think that "syntax highlighting" is what the feature is often called by Emacs users and potential Emacs users, and that changing the entry for the sake of uniformity isn't worthwhile. The feature may well be called that. I haven't said anything about what to call the feature. I'm talking about what to call the menu item that toggles "syntax highlighting". I suppose my impression that I have heard people use the phrase "syntax highlighting" often may be faulty. However, doing Google searches for "syntax highlighting" versus "highlight syntax" for either the web or usenet with or without Emacs as a qualifier suggests that the phrase "syntax highlighting" is used much more frequently than "highlight syntax". If "Highlight Syntactically" and "Highlight Syntax" are not clear, and "syntax highlighting" is a well-recognized name, then the menu item should be called "Toggle Syntax Highlighting". It should not be called "Syntax Highlighting". My point was to use a verb phrase, not a noun phrase, for a toggle menu item: "Drink Coca-Cola", not "Coca-Cola" (to use a recognizable name). My point has nothing to do with the particular feature of syntax highlighting or the recognizability of its name. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: doc string for `yank' should mention "paste"
"Drew Adams" <[EMAIL PROTECTED]> writes: > The doc string for `yank' should mention the commonly understood > "paste" operation as a (rough) synonym. Yanking is more than pasting, > but at a first approximation they are the same thing. Users > should be able to find `yank' when they do `M-x > apropos-documentation paste'. > > Similarly, the doc for `kill-region' should mention "cut" and the doc for > `kill-ring-save' should mention "copy". > > We should provide a bridge between the vocabulary that many people are used > to and the features and vocabulary of Emacs. We make this vocabulary effort > in the Edit menu (but without bridging to the Emacs jargon); we should also > do so in the doc strings of our basic commands that are similar to commands > used in other apps. > Did you actually try to do M-x apropos RET paste RET ? The apropos command has a list of aliases, e.g. paste => yank. It works for apropos-documentation as well. I The list doesn't include selection => region, but I will add that. -- Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Carbon crashes in mac_handle_mouse_event
A user reported crashes, consistently in mac_handle_mouse_event. Begin forwarded message: From: Jose Figueroa-O'Farrill <[EMAIL PROTECTED]> Date: 5 March 2006 18:23:25 GMT To: David Reitter <[EMAIL PROTECTED]> Subject: Crash reporter log Reply-To: [EMAIL PROTECTED] Hi David, José> There were a couple of Aquamacs crashes recently and I suppose José> that the damage was done during one of these crashes -- even José> though I "M-x recover-session" whenever this happens. José> The reason for the crashes, by the way, is always the same. I José> leave the powerbook unattended for a while (minutes), the José> trackpad seems to freeze, and when I touch it again, if the José> focus is on an Aquamacs frame, it will crash. David> Regarding those crashes you mention - that's rather important. Can David> you send a crash reporter log? Without such a log, I can't do much David> about it. It happened again. I was away from the keyboard for half an hour and when I came back I put my fingers on the trackpad and Aquamacs Emacs crashed. I'm attaching the Crash reporter log file. It contains several such crashes. Thanks, José Content-Description: CrashReporter Log for Aquamacs Emacs Content-Disposition: inline; filename="Aquamacs Emacs.crash.log" Content-Transfer-Encoding: 7bit ** Host Name: castalia Date/Time: 2006-03-05 18:10:07.002 + OS Version: 10.4.5 (Build 8H14) Report Version: 4 Command: Aquamacs Emacs Path:/Applications/Aquamacs Emacs.app/Contents/MacOS/Aquamacs Emacs Parent: WindowServer [62] Version: Aquamacs 0.9.8, GNU Emacs 22 (1.2a) PID:5182 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x000c Thread 0 Crashed: 0 org.gnu.AquamacsEmacs 0x0014772c mac_handle_mouse_event + 132 (macterm.c:9060) 1 com.apple.HIToolbox 0x9318dff4 DispatchEventToHandlers (EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 692 2 com.apple.HIToolbox 0x9318d74c SendEventToEventTargetInternal (OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 372 3 com.apple.HIToolbox 0x9318d5c8 SendEventToEventTargetWithOptions + 40 4 com.apple.HIToolbox 0x9322baf4 HIObject::HandleEvent (OpaqueEventHandlerCallRef*, OpaqueEventRef*) + 160 5 com.apple.HIToolbox 0x931a2210 AppleWindowDef::HandleEvent (OpaqueEventHandlerCallRef*, OpaqueEventRef*) + 1960 6 com.apple.HIToolbox 0x9318e3ac HIObject::EventHook (OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 136 7 com.apple.HIToolbox 0x9318dff4 DispatchEventToHandlers (EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 692 8 com.apple.HIToolbox 0x9318d74c SendEventToEventTargetInternal (OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 372 9 com.apple.HIToolbox 0x931944ec SendEventToEventTarget + 40 10 com.apple.HIToolbox 0x932209a0 HandleMouseEventForWindow (OpaqueWindowPtr*, OpaqueEventRef*, unsigned short) + 284 11 com.apple.HIToolbox 0x93383730 HandleMouseEvent (OpaqueEventRef*) + 368 12 com.apple.HIToolbox 0x93194858 ToolboxEventDispatcherHandler (OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 496 13 com.apple.HIToolbox 0x9318e244 DispatchEventToHandlers (EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 1284 14 com.apple.HIToolbox 0x9318d74c SendEventToEventTargetInternal (OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 372 15 com.apple.HIToolbox 0x931944ec SendEventToEventTarget + 40 16 org.gnu.AquamacsEmacs 0x00148220 XTread_socket + 344 (macterm.c: 9706) 17 org.gnu.AquamacsEmacs 0x00086474 read_avail_input + 140 (keyboard.c:6732) 18 org.gnu.AquamacsEmacs 0x00086240 get_input_pending + 148 (keyboard.c:6620) 19 org.gnu.AquamacsEmacs 0x0008b5cc detect_input_pending_run_timers + 76 (keyboard.c:9976) 20 org.gnu.AquamacsEmacs 0x001217b0 wait_reading_process_output + 2380 (process.c:4599) 21 org.gnu.AquamacsEmacs 0x00082d64 kbd_buffer_get_event + 268 (keyboard.c:3945) 22 org.gnu.AquamacsEmacs 0x0008120c read_char + 3224 (keyboard.c:2870) 23 org.gnu.AquamacsEmacs 0x000895f8 read_key_sequence + 1952 (keyboard.c:8893) 24 org.gnu.AquamacsEmacs 0x0007e64c command_loop_1 + 1084 (keyboard.c:1543) 25 org.gnu.AquamacsEmacs 0x000e9590 internal_condition_case + 336 (eval.c:1466) 26 org.gnu.AquamacsEmacs 0x0007dfac command_loop_2 + 64 (keyboard.c: 1331) 27 org.gnu.AquamacsEmacs 0x000e8f34 internal_catch + 264 (eval.c:1211) 28 org.gnu.AquamacsEmacs 0x0007df04 command_loop + 148 (keyboard.c: 1314) 29 org.gnu.AquamacsEmacs 0x0007d8d8 recursive_edit_1 + 172 (keyboard.c:1004) 30 org.gnu.AquamacsEmacs 0x0007da80 Frecursive_edit + 224 (keyboard.c:1065) 31 org.gnu.AquamacsEmacs 0x0007c538 main + 3232 (emacs.c:1792) 32 org.gnu.AquamacsEmacs 0xa060 _start + 392 (crt.c:267) 33 dyld0x8fe01048 _dyld_start + 60 Thread 0 crashed with PPC Thread State 64: srr0: 0x
RE: Added text makes `C-h b' wider than 70 chars
I don't see the change doing that, but I could be wrong. In practice, I've only seen this added to less than a dozen lines. You are right, this message does not appear often. I had overlooked that point. Therefore, putting it on a separate line would be ok. Assume the change I already sent you is installed. Would it be better to put that message on a separate line? I think so. 1) It leaves more room (flexibility) for possible future changes. 2) It helps frame-fitting (and window-fitting?) code to DTRT. Whenever possible, it's good to have *Help* buffer (and *Apropos* etc.) text respect a max line length. Code that does things to these buffers or their windows or frames can then more easily DTRT. BTW, is there a command/function that fits windows (not frames), resizing them not only vertically but also horizontally? That might be useful for some buffers with consistently short lines. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Options menu names
> > The names of the Options menu items do not use parallel > > construction. Some are noun phrases, others are verb phrases. > > Verb phrases are generally clearer. > > But some of the menu items, such as Syntax Highlighting, follow > widespread conventions that users expect. So I don't > think we should change those. > > Oh really? What widespread conventions are those? Be specific, please. I don't understand what you want me to say more than I already did. All that you did was to argue by appealing to authority: some unnamed, undescribed "widespread conventions that users expect." That's an empty argument/explanation without saying what that authority is: what conventions are you referring to? What user-expecting convention does "Syntax Highlighting" follow? And why wouldn't those conventions apply also to the menu items that are verb phrases? What criteria are used to decide which form to use? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
[emacs-unicode-2] infinite loop(?) in decode_coding
emacs-unicode-2 hangs when finding a file contains "\0".
To reproduce this symptom, create the following file and name it
test1.el:
---
(let ((temp-file-name "/tmp/test1.txt"))
(with-temp-file temp-file-name (insert "\0"))
(find-file temp-file-name))
---
then do "./emacs -Q -batch -l ./test1.el".
It looks infinite loop in coding.c:6175-6191.
backtrace attached.
Thanks,
---
Nozomu Ando
In GNU Emacs 23.0.0.2 (powerpc-apple-darwin8.5.0, X toolkit)
of 2006-03-06 on panel.jk.homeunix.org
configured using `configure '--without-carbon' '--prefix=/alpha/usr/local''
Important settings:
value of $LC_ALL: C
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: en_US
locale-coding-system: nil
default-enable-multibyte-characters: t
Major mode: Lisp Interaction
Minor modes in effect:
encoded-kbd-mode: t
auto-compression-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
global-auto-composition-mode: t
auto-composition-mode: t
line-number-mode: t
Recent input:
ESC x r e p o r t SPC e m SPC b u SPC RET
Recent messages:
(./emacs -q)
Loading encoded-kb...done
For information about the GNU Project and its goals, type C-h C-p.
Loading emacsbug...
Loading regexp-opt...done
Loading emacsbug...done
-- backtrace
(gdb) bt full
#0 decode_coding (coding=0xbffe8d90) at /work/emacs.u/src/coding.c:6175
pos = 1
undo_list = 41944073
translation_table = 41944073
carryover = 0
i = 0
#1 0x00063644 in decode_coding_gap (coding=0xbffe8d90, chars=3072372, bytes=3)
at /work/emacs.u/src/coding.c:6662
count = 59
#2 0x000e4894 in Finsert_file_contents (filename=3072584, visit=41944121,
beg=0, end=24, replace=41944073) at /work/emacs.u/src/fileio.c:4646
st = {
st_dev = 234881026,
st_ino = 5514670,
st_mode = 33188,
st_nlink = 1,
st_uid = 1001,
st_gid = 0,
st_rdev = 0,
st_atimespec = {
tv_sec = 1141622951,
tv_nsec = 0
},
st_mtimespec = {
tv_sec = 1141622981,
tv_nsec = 0
},
st_ctimespec = {
tv_sec = 1141622981,
tv_nsec = 0
},
st_size = 3,
st_blocks = 8,
st_blksize = 4096,
st_flags = 0,
st_gen = 0,
st_lspare = 0,
st_qspare = {0, 0}
}
fd = 23
inserted = 3
how_much = 0
unprocessed = 41944073
count = 59
handler = 41944073
val = 41944073
insval = 0
orig_filename = 93442451
p = 0
total = 3
not_regular = 0
read_buf =
"\000\000\000\001\000\000\000\001\240\001\001\354\220\001}\b\277\376\316\360\000\000\000\024\220\001\202l\000\0052\340\277\376\320(\000\000\000\000\000\240\n\006\000\00500\277\376\317\000\000\000\000\000\000\0051\030\000\005\371\234\277\376\317`\000\000\000\000\000\006\002\230\000\00500\277\376\317\220\277\377\321\310\000\000\000\b\000\000\000\n\000\027|[EMAIL
PROTECTED]<\000,\002\350\002\200\0049\000\000\000\026\000\000\000\000\277\376\320\340\277\377\321\310\000\000\000\r\002\200\004\t\000\027|\210\000\000\000\r"...
coding = {
id = 73,
common_flags = 7683,
mode = 0,
spec = {
iso_2022 = {
flags = 1056846,
current_invocation = {0, -1},
current_designation = {0, -1, -1, -1},
single_shifting = 0,
bol = 1
},
ccl = 0x10204e,
utf_16 = {
bom = 1056846,
endian = utf_16_big_endian,
surrogate = -1
},
emacs_mule_full_support = 1056846
},
max_charset_id = 146,
safe_charsets = 0x59139bc "",
src_multibyte = 0,
dst_multibyte = 1,
head_ascii = -1,
produced = 0,
produced_char = 0,
consumed = 0,
consumed_char = 0,
errors = 0,
error_positions = 0xd7d8d9da,
result = CODING_RESULT_SUCCESS,
src_pos = -3,
src_pos_byte = -3,
src_chars = 3,
src_bytes = 3,
src_object = 10599092,
source = 0xa00a41 "\0",
dst_pos = 1,
dst_pos_byte = 1,
dst_bytes = 17,
dst_object = 10599092,
destination = 0xa00a30 "",
chars_at_source = 0,
charbuf = 0xbffd8bb0,
charbuf_size = 16384,
charbuf_used = 0,
annotated = 0,
carryover = "\000+0\354 \000\000\000\000\000\000\000\000/!
\000\017\034\224\277\376\216\260\000\000\000|\277\376\216\340\000+\332<\000\000\000\000\003\027p,\000\000\000\001\000\000\000+\000\000\000\001\000\000\000\001\000\000\000\005",
carryover_bytes = 0,
default_char = 32,
detector = 0x56df0 ,
decoder = 0x575a8 ,
encoder = 0x5988c
}
buffer =
"\277\376\216\345\000\000\000\000\277\376\216\300\000\017<\024\277\376\217\200\204B$\b\000\017H\200\000\000\000\001\000\033\362
\000\000\000\001\277\376\216\260\000\017<\024\277\376\217pDD\204\022\003\027p,\000\000\000\003\277\376\217\200\000\000\000\001\000\000\000|\000\000\000|\000\000\000\000\000\000\000\003\000\000\000\003\000\000\000\003, pri
Crash in gc_sweep
I was editing a medium size buffer, which I had recently pasted into
from the clipboard with mouse-2.
While doing this, I did this:
M-: (define-key [?ø] (lamdba () (interactive) (insert "|"))) RET
I hit ø, and got an error -- wrong number of args
While still in the debugger, I corrected the first mistake:
C-x ESC ESC
Redo: ... (define-key global-map [?ø] (lamdba () (interactive) (insert "|")))
RET
I hit ø again, and got an error -- unknown command.
I exited the debugger and corrected the second mistake
C-x ESC ESC
Redo: ... (define-key global-map [?ø] (lambda () (interactive) (insert "|")))
RET
I now hit ø and got the expected | inserted in the buffer.
And emacs crashed...
Program received signal SIGSEGV, Segmentation fault.
0x081754c8 in gc_sweep () at alloc.c:6161
6161 if (!VECTOR_MARKED_P (vector))
(gdb) bt
#0 0x081754c8 in gc_sweep () at alloc.c:6161
#1 0x08173a09 in Fgarbage_collect () at alloc.c:5166
#2 0x0818e162 in Ffuncall (nargs=2, args=0xb070) at eval.c:2817
#3 0x0818dff0 in call1 (fn=137936913, arg1=137906097) at eval.c:2668
#4 0x08114b83 in safe_run_hooks_1 (hook=157606876) at keyboard.c:2036
#5 0x0818c274 in internal_condition_case (bfun=0x8114b69 ,
handlers=137869481, hfun=0x8114b88 ) at eval.c:1465
#6 0x08114c1e in safe_run_hooks (hook=137906097) at keyboard.c:2064
#7 0x08113085 in command_loop_1 () at keyboard.c:1623
#8 0x0818c274 in internal_condition_case (bfun=0x8112af7 ,
handlers=137914073, hfun=0x811263c ) at eval.c:1465
#9 0x0811296f in command_loop_2 () at keyboard.c:1328
#10 0x0818bcf2 in internal_catch (tag=137910305,
func=0x8112950 , arg=137869433) at eval.c:1211
#11 0x08112922 in command_loop () at keyboard.c:1307
#12 0x081123bb in recursive_edit_1 () at keyboard.c:1000
#13 0x081124fc in Frecursive_edit () at keyboard.c:1061
#14 0x08110df9 in main (argc=3, argv=0xb8a4) at emacs.c:1789
#15 0x42015574 in __libc_start_main () from /lib/tls/libc.so.6
(gdb) xba
(gdb) p vector
$1 = (struct Lisp_Vector *) 0x11
(gdb) up
#1 0x08173a09 in Fgarbage_collect () at alloc.c:5166
5166 gc_sweep ();
(gdb) do
#0 0x081754c8 in gc_sweep () at alloc.c:6161
6161 if (!VECTOR_MARKED_P (vector))
(gdb) list
6156 {
6157register struct Lisp_Vector *vector = all_vectors, *prev = 0, *next;
6158total_vector_size = 0;
6159
6160while (vector)
6161 if (!VECTOR_MARKED_P (vector))
6162{
6163 if (prev)
6164prev->next = vector->next;
6165 else
The prev pointer can give us a clue...
(gdb) p prev
$273 = (struct Lisp_Vector *) 0x8a167e0
(gdb) p *$
$274 = {
size = 1073743876,
next = 0x11,
contents = {144824549}
}
(gdb) p/x *$273
$275 = {
size = 0x4804,
next = 0x11,
contents = {0x8a1d8e5}
}
The contents is a list with all nils: (nil nil nil . nil)
(gdb) p 0x8a1d1e5
$279 = 144822757
(gdb) xtype
Lisp_Cons
(gdb) xcons
$280 = (struct Lisp_Cons *) 0x8a1d1e0
{
car = 0x837b879,
u = {
cdr = 0x8a1d1dd,
chain = 0x8a1d1dd
}
}
(gdb) p->car
$281 = 137869433
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$282 = (struct Lisp_Symbol *) 0x837b878
"nil"
(gdb) p 0x8a1d1dd
$283 = 144822749
(gdb) xtype
Lisp_Cons
(gdb) xcons
$284 = (struct Lisp_Cons *) 0x8a1d1d8
{
car = 0x837b879,
u = {
cdr = 0x8a1d1d5,
chain = 0x8a1d1d5
}
}
(gdb) p $->car
$285 = 137869433
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$286 = (struct Lisp_Symbol *) 0x837b878
"nil"
(gdb) p 0x8a1d1d5
$289 = 144822741
(gdb) xtype
Lisp_Cons
(gdb) xcons
$290 = (struct Lisp_Cons *) 0x8a1d1d0
{
car = 0x837b879,
u = {
cdr = 0x837b879,
chain = 0x837b879
}
}
(gdb)
The last objects marked are t and nil:
(gdb) p last_marked_index
$267 = 406
(gdb) p last_marked[405]
$291 = 137869481
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$292 = (struct Lisp_Symbol *) 0x837b8a8
"t"
(gdb) p last_marked[404]
$293 = 137869433
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$294 = (struct Lisp_Symbol *) 0x837b878
"nil"
(gdb) p last_marked[403]
$295 = 137869433
(gdb) p last_marked[402]
$296 = 137869481
(gdb) p last_marked[401]
$297 = 137869481
(gdb) p last_marked[400]
$298 = 137869481
.. and it continues like that for several more elements
.. until I get to the prompt - (or mini-buffer text?) where I repeated the
complex command
(gdb) p last_marked[380]
$318 = 157924317
(gdb) xtype
Lisp_Cons
(gdb) xcons
$319 = (struct Lisp_Cons *) 0x969bbd8
{
car = 0x969bbd5,
u = {
cdr = 0x969bbcd,
chain = 0x969bbcd
}
}
(gdb) p $->car
$320 = 157924309
(gdb) xtype
Lisp_Cons
(gdb) xcons
$321 = (struct Lisp_Cons *) 0x969bbd0
{
car = 0x86ccf8b,
u = {
cdr = 0x8,
chain = 0x8
}
}
(gdb) p $->car
$322 = 141348747
(gdb) xtype
Lisp_String
(gdb) xstring
$323 = (struct Lisp_String *) 0x86ccf88
"Redo: (eval-expression (quote (define-key global-map [2296] (function (lambda
nil (interactive) (insert \"|\") nil)"
(gdb)
(gdb) p handling_signal
$276 = 0
In GNU Emacs 22.0.50.66 (i686-pc-linux-gnu, X toolki
Re: Fontset for mule-unicode-0100-24ff under emacs 23?
In article <[EMAIL PROTECTED]>, Leon <[EMAIL PROTECTED]> writes: > The following font setting in ~/.emacs can display all characters in: > http://www.xahlee.org/Periodic_dosage_dir/text_editor_unicode/unicode.txt > > (create-fontset-from-fontset-spec > (concat > "-*-terminus-medium-r-*-*-16-*-*-*-*-*-fontset-unicode," > > "mule-unicode-0100-24ff:-misc-fixed-medium-r-*-*-15-*-*-*-*-*-iso10646-1"));; > (when window-system > (set-default-font "fontset-unicode")) > > However, the following font setting in ~/.Xdefault can *not* display all > characters in the above unicode.txt: > > Emacs*Fontset-0: -*-terminus-medium-r-*-*-16-*-*-*-*-*-fontset-unicode, \ > mule-unicode-0100-24ff: -misc-fixed-medium-r-*-*-15-*-*-*-*-*-iso10646-1 > Emacs.Font: fontset-unicode > Ah, thank you for finding this bug. They differ in one point; the latter has SPC after `:'. I fixed create-fontset-from-fontset-spec to accept the latter pattern both in HEAD and emacs-unicode-2. Please try again with the latest code. --- Kenichi Handa [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: doc string for `yank' should mention "paste"
The doc string for `yank' should mention the commonly understood "paste" operation as a (rough) synonym. Yanking is more than pasting, but at a first approximation they are the same thing. Users should be able to find `yank' when they do `M-x apropos-documentation paste'. Similarly, the doc for `kill-region' should mention "cut" and the doc for `kill-ring-save' should mention "copy". We should provide a bridge between the vocabulary that many people are used to and the features and vocabulary of Emacs. We make this vocabulary effort in the Edit menu (but without bridging to the Emacs jargon); we should also do so in the doc strings of our basic commands that are similar to commands used in other apps. Similarly, some basic operations on the region should mention the term "selection" as being synonymous with "region". `M-x apropos-documentation region', then search for `selection' finds nothing. These are the only terms that really need bridging: region, kill, yank, kill-ring-save. They are the ones pointed out in the jargon-translation table at http://www.emacswiki.org/cgi-bin/wiki/CategoryGlossary. The others there are frame and key-sequence, but I don't think it makes sense to bridge those via doc strings. ___ 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
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 "å ä ö Å"
---
Kenichi Handa
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Added text makes `C-h b' wider than 70 chars
This should take a step towards solving it.
! insert_string (" (shadowed)");
Yes; thank you.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: doc string for `yank' should mention "paste"
Did you actually try to do M-x apropos RET paste RET ? Yes. The apropos command has a list of aliases, e.g. paste => yank. Yes, that is helpful. It works for apropos-documentation as well. But when you scan through the 1600-line *Apropos* buffer (for `apropos-doc yank'), and you come to `yank', and you read its doc string, you do not see the word `paste'. There is nothing that says that `yank' performs pasting (in my 6/2005 snapshot on MS Windows, at least). Finding it and showing it doesn't point out that "this is it": command `yank' is what you are used to calling `paste'. The list doesn't include selection => region, but I will add that. Thanks. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mouse-2 on menu item yanks into current buffer
"Drew Adams" <[EMAIL PROTECTED]> writes: > emacs -q > > select some text, so it can be yanked > > open a menu-bar menu, and click mouse-2, instead of mouse-1, on any menu > item > > The mouse-2 command is executed in the current buffer. In a text > buffer, the copied text is yanked. In dired, the file on the curren > line is opened. > > This bug is apparently old - it occurs in Emacs 20 also. > > > In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600) > of 2005-06-26 on NONIQPC I can't reproduce this on either 21.4 or CVS from 1 March on Windows XP. GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600) of 2006-03-01 on TONKOTSU-RAMEN ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: wrong frame is current when after-make-frame-functions
The new frame is the argument to each of the hook functions. Therefore, it is useful that the selected frame is unchanged. IOW, if a hook function needs to have its argument frame selected then it should select it itself. Makes sense; thanks. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: doc string for `yank' should mention "paste"
The doc string for `yank' should mention the commonly understood "paste" operation as a (rough) synonym. Yanking is more than pasting, Thanks. ___ 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
No catch for tag: exit, nil
Minor bug. Has probably existed from day 1. emacs -q M-x exit-minibuffer produces this error: No catch for tag: exit, nil There are no doubt other such commands. Since such an error message is unfriendly, it would be better for such commands to instead raise an error saying that the command should only be used in the minibuffer. In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600) of 2005-06-26 on NONIQPC X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.3) --cflags -I../../jpeg-6b-3/include -I../../libpng-1.2.8/include -I../. ./tiff-3.6.1-2/include -I../../xpm-nox-4.2.0/include -I../../zlib-1.2.2/incl ude' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
