From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master 05a5a94: Correct calculation of CC Mode's font-lock region. Date: Mon, 30 Mar 2015 20:34:57 -0400 Message-ID: References: <20150330163859.32247.66180@vcs.savannah.gnu.org> <20150330224848.GB17661@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1427762120 16369 80.91.229.3 (31 Mar 2015 00:35:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 31 Mar 2015 00:35:20 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 31 02:35:12 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Yck97-0000KM-2q for ged-emacs-devel@m.gmane.org; Tue, 31 Mar 2015 02:35:09 +0200 Original-Received: from localhost ([::1]:36406 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yck96-0003ps-53 for ged-emacs-devel@m.gmane.org; Mon, 30 Mar 2015 20:35:08 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50982) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yck92-0003oD-2w for emacs-devel@gnu.org; Mon, 30 Mar 2015 20:35:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yck8w-0005Rg-VQ for emacs-devel@gnu.org; Mon, 30 Mar 2015 20:35:04 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:29924) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yck8w-0005Ra-RK for emacs-devel@gnu.org; Mon, 30 Mar 2015 20:34:58 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAGvvdVRBbthL/2dsb2JhbAA3gVOhb4EIgXUBAQQBViMFCwsOJhIUGA0kiBOiEYtwAiQICjwPgz4Dg3AEqDs X-IPAS-Result: AgUFAGvvdVRBbthL/2dsb2JhbAA3gVOhb4EIgXUBAQQBViMFCwsOJhIUGA0kiBOiEYtwAiQICjwPgz4Dg3AEqDs X-IronPort-AV: E=Sophos;i="5.01,1,1400040000"; d="scan'208";a="115003527" Original-Received: from 65-110-216-75.cpe.pppoe.ca (HELO pastel.home) ([65.110.216.75]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Mar 2015 20:34:58 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id F2A6B876; Mon, 30 Mar 2015 20:34:57 -0400 (EDT) In-Reply-To: <20150330224848.GB17661@acm.fritz.box> (Alan Mackenzie's message of "Mon, 30 Mar 2015 22:48:48 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:184581 Archived-At: >> Please use the present tense, even for "rename" ;-) > Do you mean I should change the commit message on that commit? Can I > actually do that? No, what's done is done. > ensure (start end) covered the location where re-rendering was needed, > the re-rendering still failed to take place. How can you tell. What does "re-render" mean for you? `jit-lock-force-redisplay' is not meant to re-run font-lock. It is only meant to refresh the display so that it reflects the `face' properties that were already set by an earlier jit-lock run. > However, when I tried changing L13 to set 'fontified to nil, the > re-rendering happened even when the location was far before `start'. Setting it to nil will cause that forces redisplay to not only re-render the buffer but also re-fontify (i.e. re-run font-lock). This is a very different need from the one jit-lock-force-redisplay is designed to address. > Assuming that jit-lock-force-redisplay is not going to work, it follows > that any buffer bits to be fontified which come earlier than > after-change-functions's `beg' need to have their 'fontified text > property set to nil, and this needs to happen at after-change time > (during redisplay is too late). This necessity even applies to > extending change regions to whole lines. Yes and no. The current code indeed has a weakness in that there's no way for a jit-lock-function (e.g. font-lock) to tell jit-lock which part of the buffer it actually did re-fontify (so that jit-lock can in turn use jit-lock-force-redisplay when needed). I've been meaning to address this for years, but never got around to it. This is only a problem when a change on one line affects the display on a *previous* line (and this is done via font-lock-extend-region-functions), so it's rarely problematic. This said, if a change on line N needs some other line M