From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Richard M. Stallman" Newsgroups: gmane.emacs.devel Subject: Re: jit-lock refontifies too much Date: Mon, 26 Sep 2005 19:56:36 -0400 Message-ID: References: <43251F5E.9040601@gmx.at> <873boa8l30.fsf-monnier+emacs@gnu.org> <4327B9C9.30406@gmx.at> <87oe6vx4he.fsf-monnier+emacs@gnu.org> <433126E3.1030905@gmx.at> <433254BF.8040205@gmx.at> <87ll1pvwyl.fsf-monnier+emacs@gnu.org> <4336A37C.70002@gmx.at> Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: sea.gmane.org 1127779349 21182 80.91.229.2 (27 Sep 2005 00:02:29 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 27 Sep 2005 00:02:29 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 27 02:02:28 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EK2uj-0000qL-OW for ged-emacs-devel@m.gmane.org; Tue, 27 Sep 2005 02:01:42 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EK2uj-0001eF-5e for ged-emacs-devel@m.gmane.org; Mon, 26 Sep 2005 20:01:41 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EK2pz-00050l-Gp for emacs-devel@gnu.org; Mon, 26 Sep 2005 19:56:48 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EK2pw-0004yB-34 for emacs-devel@gnu.org; Mon, 26 Sep 2005 19:56:44 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EK2pu-0004xG-Td for emacs-devel@gnu.org; Mon, 26 Sep 2005 19:56:43 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EK2pp-0004HV-Jk for emacs-devel@gnu.org; Mon, 26 Sep 2005 19:56:37 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1EK2po-0005ia-F5; Mon, 26 Sep 2005 19:56:36 -0400 Original-To: martin rudalics In-reply-to: <4336A37C.70002@gmx.at> (message from martin rudalics on Sun, 25 Sep 2005 15:17:48 +0200) 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:43272 Archived-At: False positives: When, for example, text within a string was never fontified before it (usually) does not have a font-lock face property. After first fontification it does. Hence my comparison above would indicate a change although there never was a buffer modification. It would be better just to keep comparing until you reach a line that previously was fontified. After all, the line that was not fontified before certainly should get fontified, if it is on the screen. But a subsequent line that was previously fontified may not need to be changed. > jit-lock-context-time is not normally zero. So what exactly is the > goal of your proposal? Is the goal to make jit-lock-context-time zero > without loss of performance? My goal is to save CPU overhead due to contextual refontification. But Stefan asked me to provide an example where contextual refontification could have visible impact. Since the question is whether there is a realistic case where it would have visible impact. If nobody really wants to set jit-lock-context-time to zero, that's not a realistic example. So we still don't know whether there is a realistic case where it would have visible impact. With ppss things are different since any "old value" gets lost together with the buffer modification. Hence, I can't use ppss to establish the old value when refontifying. Yes. That is why I suggested recording these ppss values in text properties of the first character on a line--so that they would stay around for comparison later. That would be overly expensive. I rewrote all this with ppss, two markers, a before-change-functions hook and without any text properties. It seems to work but needs some further testing. That is interesting. I would not have expected it to work. However, this would require doing that computation for each change, and that could be rather expensive, right? One advantage for the idea of saving it in a text property for the first character on each line is that it only has to be checked when it is time to refontify. Another possible advantage is: if things are not in sync for the first line after the end of the changed text, it might be in sync on a subsequent line, and that could avoid refontifying most of the lines on the screen.