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: jit-lock refontifies too much Date: Wed, 28 Sep 2005 10:16:55 -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> <433A8C09.8050901@gmx.at> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1127917512 578 80.91.229.2 (28 Sep 2005 14:25:12 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 28 Sep 2005 14:25:12 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 28 16:25:06 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EKcpA-0000UP-5W for ged-emacs-devel@m.gmane.org; Wed, 28 Sep 2005 16:22:20 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EKcp9-0005px-5p for ged-emacs-devel@m.gmane.org; Wed, 28 Sep 2005 10:22:19 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EKclB-00041E-3n for emacs-devel@gnu.org; Wed, 28 Sep 2005 10:18:14 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EKcl0-0003vl-5u for emacs-devel@gnu.org; Wed, 28 Sep 2005 10:18:03 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EKckz-0003tr-Ls for emacs-devel@gnu.org; Wed, 28 Sep 2005 10:18:01 -0400 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EKck5-0001ge-4o; Wed, 28 Sep 2005 10:17:05 -0400 Original-Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id B74922CF62A; Wed, 28 Sep 2005 10:17:04 -0400 (EDT) Original-Received: from asado.iro.umontreal.ca (asado.iro.umontreal.ca [132.204.24.84]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 849BC4AC010; Wed, 28 Sep 2005 10:16:56 -0400 (EDT) Original-Received: by asado.iro.umontreal.ca (Postfix, from userid 20848) id 6BF1DE6C17; Wed, 28 Sep 2005 10:16:56 -0400 (EDT) Original-To: martin rudalics In-Reply-To: <433A8C09.8050901@gmx.at> (martin rudalics's message of "Wed, 28 Sep 2005 14:26:49 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-4.847, requis 5, autolearn=not spam, AWL 0.05, BAYES_00 -4.90) X-MailScanner-From: monnier@iro.umontreal.ca 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:43330 Archived-At: >> My gut feeling is that this is way past the point of diminishing returns. >> Already his optimization is rarely noticeable, but breaks a couple >> (rare) special cases. > In the patch below I provide three variables recording the behavior of > contextual fontification > jit-lock-fail-change records the number of modifications the patch > couldn't handle because a buffer change did not occur within the bounds > of a previous change > jit-lock-fail-context records the number of buffer modifications where > syntactic context changed, including modifications of elisp doc-strings > jit-lock-succ-context records the number of buffer modifications where > contextual refontification was avoided > I believe that the patch would be useful if and only if (1) it does not > break existing code, (2) redisplay doesn't suffer noticeable delay due > to before-change-functions, (3) the value of jit-lock-succ-context > exceeds the sum of jit-lock-fail-change and jit-lock-fail-context > significantly, that is by a factor of two or three at least. I expect number 2 won't be a problem (or can be made into a nonproblem). I also expect number 3 won't be a problem; what's your experience? Number 1 is what concerns me. > + ;; Refontify contextually if > + ;; 1. paren depth equals 1 before or after change(s) in Lisp > + ;; modes - needed to handle doc-strings, > + ;; 2. character that terminates containing string changed, > + ;; 3. comment status changed, > + ;; 4. comment type changed. This is ugly: problems specific to emacs-lisp-mode should not be fixed in jit-lock but in lisp-mode.el. I'm not sure how to fix it, tho. Maybe you could (in lisp-font-lock-syntactic-face-function) place a jit-lock-defer-multiline property. > + (if (or (and (memq major-mode '(emacs-lisp-mode lisp-mode)) > + (or (= (nth 0 ppss) 1) > + (= (nth 0 jit-lock-context-ppss) 1))) Here I'd just compare (not (equal (nth 0 ppss) (nth 0 jit-lock-context-ppss))). > +(defun jit-lock-before-change (start end) > + "Calculate ppss at beginning of first line following END. > +Installed on `before-change-functions' when contextual fontification is > +enabled. START and END are start and end of the changed text." > + (when (and jit-lock-mode jit-lock-context-unfontify-pos > + ;; Quit unless `jit-lock-context-unfontify-pos' is below START. > + (> jit-lock-context-unfontify-pos start) > + ;; Do this once for a sequence of modifications only, that is, iff > + ;; `jit-lock-context-start' does not point into current buffer. > + (not (eq (marker-buffer jit-lock-context-start) > + (current-buffer)))) > + (when (marker-buffer jit-lock-context-start) > + ;; `jit-lock-context-start' points into another buffer. Set > + ;; `jit-lock-context-unfontify-pos' in that buffer. > + (with-current-buffer (marker-buffer jit-lock-context-start) > + (setq jit-lock-context-unfontify-pos > + (min jit-lock-context-unfontify-pos > + jit-lock-context-start)))) > + (save-excursion > + ;; Install markers. > + (set-marker jit-lock-context-start > + (progn (goto-char start) (line-beginning-position))) > + (set-marker jit-lock-context-end > + (progn (goto-char end) (line-beginning-position 2))) > + ;; Record ppss at `jit-lock-context-end'. > + (setq jit-lock-context-ppss (syntax-ppss jit-lock-context-end))))) It's not trivial to convince oneself that your code is correct. I'd rather you arrange somehow to leave as much of the code unchanged. Among other things, jit-lock-context-unfontify-pos should be set unconditionally in jit-lock-after-change, as before. Only if your optimization applies, then you should reset jit-lock-context-unfontify-pos. Basically make it obvious that as long as your optimization does not succeed, the behavior is unchanged. The code that does (when (marker-buffer jit-lock-context-start) ...) above is the kind of "oops let's fix things back" kind of thing I'd rather not see. Stefan