From mboxrd@z Thu Jan 1 00:00:00 1970 Path: quimby.gnus.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Mysterious redisplay problem and a trap in xdisp.c Date: Sat, 9 Feb 2002 22:17:39 -0700 (MST) Message-ID: <200202100517.g1A5Hd106081@aztec.santafe.edu> References: <20020207125930.847AA7C035@mail.filanet.dk> <5xheoraead.fsf@kfs2.cua.dk> Reply-To: rms@gnu.org NNTP-Posting-Host: quimby2.netfonds.no X-Trace: quimby2.netfonds.no 1013318873 19045 195.204.10.66 (10 Feb 2002 05:27:53 GMT) X-Complaints-To: usenet@quimby2.netfonds.no NNTP-Posting-Date: 10 Feb 2002 05:27:53 GMT Cc: emacs-devel@gnu.org Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby2.netfonds.no with esmtp (Exim 3.12 #1 (Debian)) id 16ZmWi-0004wz-00 for ; Sun, 10 Feb 2002 06:27:48 +0100 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.33 #1 (Debian)) id 16ZmNK-0000T0-00; Sun, 10 Feb 2002 00:18:06 -0500 Original-Received: from pele.santafe.edu ([192.12.12.119]) by fencepost.gnu.org with esmtp (Exim 3.33 #1 (Debian)) id 16ZmMv-0000Qi-00; Sun, 10 Feb 2002 00:17:41 -0500 Original-Received: from aztec.santafe.edu (aztec [192.12.12.49]) by pele.santafe.edu (8.9.3/8.9.3) with ESMTP id WAA26208; Sat, 9 Feb 2002 22:17:39 -0700 (MST) Original-Received: (from rms@localhost) by aztec.santafe.edu (8.10.2+Sun/8.9.3) id g1A5Hd106081; Sat, 9 Feb 2002 22:17:39 -0700 (MST) X-Authentication-Warning: aztec.santafe.edu: rms set sender to rms@aztec using -f Original-To: storm@cua.dk In-reply-to: <5xheoraead.fsf@kfs2.cua.dk> (storm@cua.dk) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: quimby.gnus.org gmane.emacs.devel:937 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:937 > While typing in some text in a buffer, emacs suddenly decides to > insert a new line instead of the character I typed. But if I do C-l, > there is only one line, and the character I typed magically reappears. Actually it did not "insert a newline". This evidence proves that. The bug is in redisplay. If I comment out the call to make_gap_smaller in make_gap, the problem goes away! This may be of some help, but the reliable way to track this down is to step thru redisplay when the problem happens. Anything else is just guesswork. There is a chance this "clue" will lead someone to think of a possible cause, but if that doesn't happen, the reliable way is likely to be the fastest way. Don't waste your time staring at make_gap_smaller. You know what it does. That's not where the problem is. Here's what it makes me think of: is there anything in redisplay that points to a buffer character by its address rather than by its character number? Anything that might live across the computation of the mode line? Is the problem reliably reproducible now? If not, maybe you can make that happen by having some function called from mode-line-format execute (garbage-collect). _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel