From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: frame and message redisplay skipped if next input already present? Date: Sat, 15 Jan 2005 23:09:18 -0800 Message-ID: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1105860011 8007 80.91.229.6 (16 Jan 2005 07:20:11 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 16 Jan 2005 07:20:11 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 16 08:20:05 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1Cq4hg-0000Hs-00 for ; Sun, 16 Jan 2005 08:20:04 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Cq4tT-0007Kg-Jf for ged-emacs-devel@m.gmane.org; Sun, 16 Jan 2005 02:32:15 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Cq4sy-0007Cm-O1 for emacs-devel@gnu.org; Sun, 16 Jan 2005 02:31:45 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Cq4sj-00076R-Bh for emacs-devel@gnu.org; Sun, 16 Jan 2005 02:31:30 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Cq4sj-00072w-4x for emacs-devel@gnu.org; Sun, 16 Jan 2005 02:31:29 -0500 Original-Received: from [148.87.2.204] (helo=inet-mail4.oracle.com) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1Cq4Xi-0003AS-CL for emacs-devel@gnu.org; Sun, 16 Jan 2005 02:09:46 -0500 Original-Received: from inet-mail4.oracle.com (localhost [127.0.0.1]) by inet-mail4.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j0G79aXT019609 for ; Sat, 15 Jan 2005 23:09:36 -0800 (PST) Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.191.50]) by inet-mail4.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j0G79XFr019591 for ; Sat, 15 Jan 2005 23:09:34 -0800 (PST) Original-Received: from rgmsgw301.us.oracle.com (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j0G79Ych029620 for ; Sun, 16 Jan 2005 00:09:34 -0700 Original-Received: from dradamslap (dhcp-amer-csvpn-gw2-141-144-73-49.vpn.oracle.com [141.144.73.49]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id j0G79WEQ029602 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sun, 16 Jan 2005 00:09:34 -0700 Original-To: "Emacs-Devel" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:32262 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:32262 I don't know if this is a bug or if I just don't know how to manage this properly. I've searched the doc and source code, but I haven't found the info I need. Consider this function (this is a pared-down version but it still shows the pb): (defun bg () (interactive) (let ((indx 0) evnt) (while (progn (setq evnt (read-event) indx (1+ indx)) (not (equal evnt 6))) ; C-f to stop (set-background-color (nth indx x-colors)) (message "New bg: %s" (cdr (assq 'background-color (frame-parameters))))))) This just changes the background color with each key press (C-f stops the loop). Again, this is not the real functionality I use, but it shows the problem. When I hold down a key continually, so that the loop repeats quickly, the text in the frame is not redisplayed, and the message is not updated (a previous message remains in the echo area). By the frame not being redisplayed, I mean that it appears temporarily empty, or at least partly blank - the bottom portion is blank, as if the frame didn't have time to be completely "painted" before the next loop cycle. When I stop holding down the key, the frame text is updated correctly and the latest message is shown in the echo area. IOW, while I hold down a key, I see only the initial (or an intermediate, out-of-date) message and a more-or-less blank frame (but the background color is updated properly and immediately, it seems). When I stop, things appear normal again. In a virgin emacs -q the problem doesn't really manifest itself very well, but it seems to get worse as I load more of my code (e.g. more of the frame appears blank when holding down a key). I haven't been able to determine anything specific in my environment that causes this. I'm guessing that there is not one single thing that causes it, but rather that the frame & `message' display are just slowed down because of various code I use, and that the already-available key input somehow suppresses the display of `message' and the frame contents. IOW, I'm guessing that `message' and the frame-contents update (but not the color change) are _skipped_ - the available input being processed without them - perhaps as some kind of display optimization. Anyway, I'm wondering if someone has an idea what's going on and what I can do about it. Is it "normal" that this would happen if display is slowed down a bit and input is received quickly? If so, is there some way I can _force_ the `message' to appear and the frame contents to be displayed at each loop go-round? IOW, I would like the logic of the loop to be respected rigorously, without any steps being skipped: 1) read event, 2) update frame color and redisplay its contents, 3) write `message'. I would rather that the entire loop cycle be slowed down than that any of the steps be skipped. This behavior is very annoying - there is no ongoing feedback for each frame change as there should be. I do not get this behavior in Emacs 20, BTW, using the same code - there is no such problem there: the code just does what it says. Thanks for any insight on this. - Drew In GNU Emacs 21.3.50.1 (i386-mingw-nt5.1.2600) of 2004-07-26 on BERATUNG4 configured using `configure --with-gcc (3.3) --cflags -I../../jpeg-6b-1/include -I../../libpng-1.2.4-1/include -I.. /../tiff-3.5.7/include -I../../xpm-nox-4.2.0/include -I../../zlib-1.1.4-1/in clude'