[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: precedence of the keymap property
From: |
Kim F. Storm |
Subject: |
Re: precedence of the keymap property |
Date: |
03 Jan 2002 11:41:20 +0100 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 |
Richard Stallman <address@hidden> writes:
> I would suggest to promote the keymap property to take precedence
> over the minor mode keymaps.
>
> I wrote that change myself. The resulting Emacs does basically work.
> Do you want to see if it achieves the goal?
For one thing, you need to make the corresponding change in keymap.c
in the functions current-active-maps and key-binding.
Maybe describe-buffer-bindings too.
But your fix doesn't work for me (emacs traps):
Start emacs -q, enter the *scratch* buffer, clean it of all
initial text, and then enter the following lines:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
(setq mymap (make-sparse-keymap)) C-j
(put-text-property 10 20 'keymap mymap) C-j
I.e. the contents of the *scratch* buffer is:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
(setq mymap (make-sparse-keymap))
(keymap)
(put-text-property 10 20 'keymap mymap)
nil
Now move the cursor to the top of the buffer on the first `a', and
move right using the right arrow key. When I reach the 10th `a',
emacs traps:
Program received signal SIGSEGV, Segmentation fault.
0x80da77d in access_keymap (map=1184252956, idx=405428244, t_ok=2, noinherit=0,
autoload=1) at keymap.c:541
541 for (tail = XCDR (map);
(gdb) bt
#0 0x80da77d in access_keymap (map=1184252956, idx=405428244, t_ok=2,
noinherit=0, autoload=1) at keymap.c:541
#1 0x80d5b38 in follow_key (key=405428244, nmaps=4, current=0xbffff3ec,
defs=0xbffff3dc, next=0xbffff3ec) at keyboard.c:7853
#2 0x80d6b43 in read_key_sequence (keybuf=0xbffff530, bufsize=30,
prompt=405204412, dont_downcase_last=0, can_return_switch_frame=1,
fix_current_buffer=1) at keyboard.c:8582
#3 0x80cea5e in command_loop_1 () at keyboard.c:1437
#4 0x811c7a4 in internal_condition_case (bfun=0x80ce79c <command_loop_1>,
handlers=405300804, hfun=0x80ce43c <cmd_error>) at eval.c:1298
#5 0x80ce6a5 in command_loop_2 () at keyboard.c:1243
#6 0x811c3a2 in internal_catch (tag=405262156, func=0x80ce688 <command_loop_2>,
arg=405204412) at eval.c:1058
#7 0x80ce65f in command_loop () at keyboard.c:1222
#8 0x80ce239 in recursive_edit_1 () at keyboard.c:948
#9 0x80ce343 in Frecursive_edit () at keyboard.c:1004
#10 0x80cd418 in main (argc=2, argv=0xbffffa74, envp=0xbffffa80) at emacs.c:1600
(gdb)
The `map' parameter is invalid:
(gdb) p map
$1 = 1184252956
(gdb) xcons
$2 = (struct Lisp_Cons *) 0x696441c
Cannot access memory at address 0x696441c
If I look at read_key_sequence, this is what I find:
(gdb) p key
$25 = 405428244
(gdb) xsymbol
$26 = (struct Lisp_Symbol *) 0x82a5814
0x81850a8 "right"
(gdb)
(gdb) p first_binding
$11 = 0
(gdb) p nmaps
$12 = 4
(gdb) p current_global_map
$13 = 1479091604
(gdb) p submaps[3]
$14 = 1479091604
(gdb) xcons
$15 = (struct Lisp_Cons *) 0x8292594
{
car = 0x18285c5c,
cdr = 0x5829258c
}
(gdb) p orig_local_map
$16 = 1480633052
(gdb) p submaps[2]
$17 = 1480633052
(gdb) xcons
$18 = (struct Lisp_Cons *) 0x840aadc
{
car = 0x18285c5c,
cdr = 0x5840ab24
}
(gdb) p submaps[1]
$19 = 135093848
(gdb) xcons
$20 = (struct Lisp_Cons *) 0x80d5e58
{
car = 0x8be84589,
cdr = 0x2671841d
}
(gdb) p orig_keymap
$21 = 1481299484
(gdb) xcons
$22 = (struct Lisp_Cons *) 0x84ad61c
{
car = 0x18285c5c,
cdr = 0x1826edbc
}
(gdb) p submaps[0]
$23 = 1184252956
(gdb) xcons
$24 = (struct Lisp_Cons *) 0x696441c
Cannot access memory at address 0x696441c
(gdb)
So somehow, the contents of submaps[0] doesn't correspond to
orig_keymap.
Also, the car of sybmaps[1] doesn't look right, so that might
have been overwritten(?) too...
(gdb) p 0x18285c5c
$27 = 405298268
(gdb) xsymbol
$28 = (struct Lisp_Symbol *) 0x8285c5c
0x8178ed4 "keymap"
(gdb) p 0x8be84589
$29 = 2347255177
(gdb) xsymbol
$30 = (struct Lisp_Symbol *) 0xbe84589
Cannot access memory at address 0xbe8458d
(gdb)
I tried the same recepy with 21.1, and it doesn't trap.
++kfs