bug-gnu-emacs
[Top][All Lists]
Advanced

[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?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]