compose and blink-cursor-mode

compose and blink-cursor-mode

[Luc Habert]

In GNU Emacs 21.3.1 (i386--freebsd, X toolkit, Xaw3d scroll bars)
 of 2003-10-08 on fregate
configured using `configure  --x-libraries=/usr/X11R6/lib --x-includes=/usr/X11R6/include --prefix=/usr/local/util/packages/emacs-21.3 i386--freebsd'
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: fr_FR.ISO_8859-1
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  locale-coding-system: iso-latin-1
  default-enable-multibyte-characters: t

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

Hi.

This is a bug that I met only on freebsd boxes (freebsd 5 actually, I did
not test it on freebsd 4), with emacs 21.2 as well as 21.3 running in
XWindow mode. The XFree86 installed is version 4.3.0.

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.
If I hit another key (even a non-printable one, like shift), the letter
appears immediately.

Re: compose and blink-cursor-mode

[Richard Stallman]

    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?  Maybe you can find out what it is waiting for, and
why.

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.

Re: compose and blink-cursor-mode

[Richard Stallman]

    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?

Re: compose and blink-cursor-mode

[Luc Habert]

On Thu, Oct 30, 2003 at 07:08:08PM -0500, Richard Stallman wrote:
> Does the bug happen using the Emacs sources in CVS on savannah.gnu.org?

Yes, it does. 

I haven't had time to gdbify the issue deeper, I'll let you know when I
have.