[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: compose and blink-cursor-mode
From: |
Richard Stallman |
Subject: |
Re: compose and blink-cursor-mode |
Date: |
Thu, 30 Oct 2003 19:08:08 -0500 |
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
That is the ordinary place where Emacs waits for a command.
So what is needed is to investigate whether the last character you
typed has already been read and processed by Emacs. For instance, has
read_key_sequence read anything yet? If so, why did it decide that
the key sequence was not finished?
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.
That could be a clue. But I can't go from there to guessing what is
wrong. If you study what tells the main-program level of Emacs to
wake up, and then see why the code that handles the compose-sequence
fails to do that, you could find the bug.
Does the bug happen using the Emacs sources in CVS on savannah.gnu.org?