From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Lennart Borgman (gmail)" Newsgroups: gmane.emacs.devel Subject: Re: major mode changes increments buffer-modified-tick Date: Tue, 30 Sep 2008 22:21:07 +0200 Message-ID: <48E28A33.6040106@gmail.com> References: <48E28385.9000104@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1222806108 2201 80.91.229.12 (30 Sep 2008 20:21:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 30 Sep 2008 20:21:48 +0000 (UTC) To: Emacs Devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 30 22:22:46 2008 connect(): Connection refused Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Kklk5-00026C-Cd for ged-emacs-devel@m.gmane.org; Tue, 30 Sep 2008 22:22:46 +0200 Original-Received: from localhost ([127.0.0.1]:41389 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kklj2-00087c-Ae for ged-emacs-devel@m.gmane.org; Tue, 30 Sep 2008 16:21:40 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kklif-00080P-5J for emacs-devel@gnu.org; Tue, 30 Sep 2008 16:21:17 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kklid-0007zn-Jp for emacs-devel@gnu.org; Tue, 30 Sep 2008 16:21:16 -0400 Original-Received: from [199.232.76.173] (port=51511 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kklid-0007zg-EU for emacs-devel@gnu.org; Tue, 30 Sep 2008 16:21:15 -0400 Original-Received: from ch-smtp02.sth.basefarm.net ([80.76.149.213]:47912) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Kklib-00011O-Tk for emacs-devel@gnu.org; Tue, 30 Sep 2008 16:21:14 -0400 Original-Received: from c83-254-151-87.bredband.comhem.se ([83.254.151.87]:59631 helo=[127.0.0.1]) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1KkliZ-0002bA-8V for emacs-devel@gnu.org; Tue, 30 Sep 2008 22:21:11 +0200 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666 In-Reply-To: <48E28385.9000104@gmail.com> X-Enigmail-Version: 0.95.7 X-Antivirus: avast! (VPS 080930-0, 2008-09-30), Outbound message X-Antivirus-Status: Clean X-Originating-IP: 83.254.151.87 X-Scan-Result: No virus found in message 1KkliZ-0002bA-8V. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1KkliZ-0002bA-8V 3d5c60383520cea8a457d5ddc0b3dc19 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6? (barebone, rare!) 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: news.gmane.org gmane.emacs.devel:104267 Archived-At: Lennart Borgman (gmail) wrote: > Why? (I am looking for a subtle bug and wonder if something is wrong here.) The bug I am hunting is that buffer get modified status when I jump to a new location. At the same time I get the following entry in undo list: buffer-undo-list is a variable defined in `buffer.c'. Its value is (nil (t 18654 . 5897)) The doc for buffer-undo-list says An entry (t HIGH . LOW) indicates that the buffer previously had "unmodified" status. HIGH and LOW are the high and low 16-bit portions of the visited file's modification time, as of that time. If the modification time of the most recent save is different, this entry is obsolete. Now (visited-file-modtime) gives just these figures. If I do the same jump again I get a new similar entry (or entries, there is a nil too): buffer-undo-list is a variable defined in `buffer.c'. Its value is (nil (t 18654 . 5897) nil (t 18654 . 5897)) But this does not happen just when jumping. It happens with mumamo, and I think it is only if there is a call to (top-level) in a timer before this. This is starting to look like a bug report ... - but I am not sure where yet, in mumamo or Emacs. Here is how I reproduce it: I open the file nxhtml.html (which comes with nXhtml). - Go to line 10 (which is a css-mode chunk) - Go to line 1 (which is a html-mode chunk) - Go to line 165 (which is another html-mode chunk) Before moving from a chunk I wait until the major mode has been set in the chunk. In this case there is a call to top-level after the major mode has been set in the chunk. The buffer does not get modified status if I instead do step 3 quickly, before the timer that changes the major mode jumps in. In this case the major mode is instead changed in pre-command-hook. In this case the call to top-level is not done. So I am leaning towards that there is something strange with top-level and timers.