From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: Re: [kzeitler@sfsws1.de.lucent.com: Buffer sometimes changes to modified with truncate-partial-width-windows set to nil] Date: Tue, 15 Aug 2006 19:19:04 -0400 Message-ID: <877j19lh93.fsf@stupidchicken.com> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1155683900 18686 80.91.229.2 (15 Aug 2006 23:18:20 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 15 Aug 2006 23:18:20 +0000 (UTC) Cc: kifer@cs.sunysb.edu, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 16 01:18:16 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GD8Aa-0007uk-Td for ged-emacs-devel@m.gmane.org; Wed, 16 Aug 2006 01:18:01 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GD8Aa-0005J1-7p for ged-emacs-devel@m.gmane.org; Tue, 15 Aug 2006 19:18:00 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GD8AM-0005HB-Pv for emacs-devel@gnu.org; Tue, 15 Aug 2006 19:17:46 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GD8AM-0005G7-1e for emacs-devel@gnu.org; Tue, 15 Aug 2006 19:17:46 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GD8AL-0005Fs-Ur for emacs-devel@gnu.org; Tue, 15 Aug 2006 19:17:45 -0400 Original-Received: from [18.19.1.138] (helo=cyd) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GD8GU-0004qg-CW for emacs-devel@gnu.org; Tue, 15 Aug 2006 19:24:06 -0400 Original-Received: by cyd (Postfix, from userid 1000) id B0D214E2AB; Tue, 15 Aug 2006 19:19:04 -0400 (EDT) Original-To: monnier@iro.umontreal.ca In-Reply-To: (Richard Stallman's message of "Wed, 09 Aug 2006 21:13:28 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) 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:58423 Archived-At: > From: Klaus Zeitler > Subject: Buffer sometimes changes to modified with > truncate-partial-width-windows set to nil > > 1. start emacs -Q > 2. in scratch buffer evaluate the following 2 expressions > (setq ediff-split-window-function 'split-window-horizontally) > (setq truncate-partial-width-windows nil) > 3. M-x ediff-files file1 file2 > > Now when I move (with in Ediff Control Panel) from diff to diff, it's > only a matter of time till at least one of the buffers changes the > buffer-modified flag without any apparent reason. This seems to be an effect of the "orig-start" code that Stefan added to `jit-lock-fontify-now'. The problem goes away if this chunk is commented out. I don't know why the chunk has the effect, though; as far as I can tell, it ought to preserve buffer modification status since everything is wrapped in a `with-buffer-prepared-for-jit-lock' macro. I can confirm that `buffer-modified-p' is nil when the timer function is run: ;; The redisplay engine has already rendered the buffer up-to ;; `orig-start' and won't notice if the above jit-lock-functions ;; changed the appearance of any part of the buffer prior ;; to that. So if `start' is before `orig-start', we need to ;; cause a new redisplay cycle after this one so that any changes ;; are properly reflected on screen. ;; To make such repeated redisplay happen less often, we can ;; eagerly extend the refontified region with ;; jit-lock-after-change-extend-region-functions. (when (< start orig-start) (lexical-let ((start start) (orig-start orig-start) (buf (current-buffer))) (run-with-timer 0 nil (lambda () (with-buffer-prepared-for-jit-lock (put-text-property start orig-start 'fontified t buf)))))) Even more bizaarely, tweaking set-buffer-modified-p inside the `with-buffer-prepared-for-jit-lock' block, as shown below, also causes the bug to go away. By right, it should do nothing. The set-buffer-modified-p call can be put later in `jit-lock-fontify-now', but putting it any earlier causes the bug to resurface. Anyone have any idea what's going on here? *** emacs/lisp/jit-lock.el.~1.53.~ 2006-08-15 18:27:36.000000000 -0400 --- emacs/lisp/jit-lock.el 2006-08-15 19:16:50.000000000 -0400 *************** *** 368,373 **** --- 368,375 ---- ;; We mark it first, to make sure that we don't indefinitely ;; re-execute this fontification if an error occurs. (put-text-property start next 'fontified t) + (set-buffer-modified-p nil) + (condition-case err (run-hook-with-args 'jit-lock-functions start next) ;; If the user quits (which shouldn't happen in normal on-the-fly