From: Richard Stallman <rms@gnu.org>
Cc: bug-gnu-emacs@gnu.org
Subject: Re: compose and blink-cursor-mode
Date: Thu, 30 Oct 2003 19:08:08 -0500 [thread overview]
Message-ID: <E1AFMpk-0000OZ-S3@fencepost.gnu.org> (raw)
In-Reply-To: <20031030173944.GA21474@drakkar.ens.fr> (message from Luc Habert on Thu, 30 Oct 2003 18:39:45 +0100)
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?
next prev parent reply other threads:[~2003-10-31 0:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-27 13:28 compose and blink-cursor-mode Luc Habert
2003-10-28 20:39 ` Richard Stallman
2003-10-30 17:39 ` Luc Habert
2003-10-31 0:08 ` Richard Stallman [this message]
2003-10-31 19:20 ` Luc Habert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E1AFMpk-0000OZ-S3@fencepost.gnu.org \
--to=rms@gnu.org \
--cc=bug-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).