Re: compose and blink-cursor-mode

[Luc Habert]

On Tue, Oct 28, 2003 at 03:39:37PM -0500, Richard Stallman wrote:
>     When blink-cursor-mode is disabled (and only in that case), and I try
>     to input a character using the compose key, a seemingly random time
>     (roughly between one and thirty seconds) elapses between the time I
>     release the last key of the compose sequence and the time the letter
>     shows up on the screen.
> 
> Can you run emacs under gdb and suspend it while it is waiting, and
> make a backtrace? 

Well, here it is :

#0  0x284a2fe3 in select () from /usr/lib/libc.so.5
#1  0x0814d118 in wait_reading_process_input (time_limit=30, microsecs=0,
    read_kbd=268435455, do_display=1) at process.c:2597
#2  0x08055f51 in sit_for (sec=30, usec=0, reading=1, display=1,
    initial_display=0) at dispnew.c:6240
#3  0x080d057a in read_char (commandflag=1, nmaps=2, maps=0xbfbfef60,
    prev_event=405216260, used_mouse_menu=0xbfbfefa8) at keyboard.c:2518
#4  0x080d6e05 in read_key_sequence (keybuf=0xbfbff0c0, bufsize=30,
    prompt=405216260, dont_downcase_last=0, can_return_switch_frame=1,
    fix_current_buffer=1) at keyboard.c:8209
#5  0x080ceb16 in command_loop_1 () at keyboard.c:1451
#6  0x08120b84 in internal_condition_case (bfun=0x80ce7f0 <command_loop_1>,
    handlers=405338332, hfun=0x80ce414 <cmd_error>) at eval.c:1267
#7  0x080ce6b8 in command_loop_2 () at keyboard.c:1245
#8  0x08120775 in internal_catch (tag=93, func=0x80ce698 <command_loop_2>,
    arg=405216260) at eval.c:1030
#9  0x080ce646 in command_loop () at keyboard.c:1224
#10 0x080ce1e6 in recursive_edit_1 () at keyboard.c:950
#11 0x080ce30c in Frecursive_edit () at keyboard.c:1006
#12 0x080cd288 in main (argc=5, argv=0xbfbff3c4, envp=0xbfbff3dc)
    at emacs.c:1547
#13 0x0804eb35 in _start ()

(It was somewhat tricky to attach to the running emacs at the right time,
because any X event that reaches emacs wakes it up. The method I used is
running emacs inside an Xnest, and then use a key sequence grabbed by the WM
of the toplevel X server to transfer focus in that toplevel server from the
Xnest window to the gdb window. Since the keys were grabbed by the WM, Xnest
did not receive a KeyEvent (only a FocusOutEvent) so that it transmitted no
event to the emacs running inside of him.)

Now, the select was called from function wait_reading_process_input at line
2597.

I am not familiar with the way emacs works, so that I cannot report
accurately what happens, I can just report what I saw while running emacs
under gdb while typing a compose sequence. For all three keypresses of the
sequence, the select returns, then emacs does a lot of things I don't
understand, but a quick glance at some of the comments seems to indicate
that emacs sees no keyboard input (I guess it is normal for the first two
keys of the compose sequence : they remain inside Xlib's guts), even for the
last keypress of the compose sequence : emacs enters again select, and
leaves it only at the next event, and then realises there is some keyboard
input pending.

I hope these observations may be of use to you. I can send you deeper
reports if you tell me where to look.