From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#4835: 23.1; Improper `Invalid face reference' messages. Performance degraded. Date: Sat, 31 Oct 2009 00:41:12 -0700 Message-ID: References: <26C434DFBD78465BB3861200D6CAE453@us.oracle.com> Reply-To: Drew Adams , 4835@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1256976457 9175 80.91.229.12 (31 Oct 2009 08:07:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 31 Oct 2009 08:07:37 +0000 (UTC) Cc: bug-gnu-emacs@gnu.org, 4835@emacsbugs.donarmstrong.com To: "'Stefan Monnier'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Oct 31 09:07:29 2009 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1N48zh-0005es-6E for geb-bug-gnu-emacs@m.gmane.org; Sat, 31 Oct 2009 09:07:29 +0100 Original-Received: from localhost ([127.0.0.1]:50008 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N48zg-0000RS-Dy for geb-bug-gnu-emacs@m.gmane.org; Sat, 31 Oct 2009 04:07:28 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N48zb-0000RB-NB for bug-gnu-emacs@gnu.org; Sat, 31 Oct 2009 04:07:23 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N48zW-0000QU-SJ for bug-gnu-emacs@gnu.org; Sat, 31 Oct 2009 04:07:23 -0400 Original-Received: from [199.232.76.173] (port=57551 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N48zW-0000QQ-Em for bug-gnu-emacs@gnu.org; Sat, 31 Oct 2009 04:07:18 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:57335) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1N48zV-0002xx-PX for bug-gnu-emacs@gnu.org; Sat, 31 Oct 2009 04:07:18 -0400 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9V87EUW009286; Sat, 31 Oct 2009 01:07:15 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.14.3/8.14.3/Submit) id n9V7o6st007030; Sat, 31 Oct 2009 00:50:07 -0700 Resent-Date: Sat, 31 Oct 2009 00:50:07 -0700 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: "Drew Adams" Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Sat, 31 Oct 2009 07:50:06 +0000 Resent-Message-ID: Resent-Sender: owner@emacsbugs.donarmstrong.com X-Emacs-PR-Message: followup 4835 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 4835-submit@emacsbugs.donarmstrong.com id=B4835.12569750056432 (code B ref 4835); Sat, 31 Oct 2009 07:50:06 +0000 Original-Received: (at 4835) by emacsbugs.donarmstrong.com; 31 Oct 2009 07:43:25 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from rgminet11.oracle.com (rcsinet11.oracle.com [148.87.113.123]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9V7hNBv006429 for <4835@emacsbugs.donarmstrong.com>; Sat, 31 Oct 2009 00:43:24 -0700 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rgminet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n9V7ipQJ014756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 31 Oct 2009 07:44:53 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n9V7GJdC017405; Sat, 31 Oct 2009 07:44:37 GMT Original-Received: from abhmt018.oracle.com by acsmt353.oracle.com with ESMTP id 20742715111256974874; Sat, 31 Oct 2009 00:41:14 -0700 Original-Received: from dradamslap1 (/141.144.80.25) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 31 Oct 2009 00:41:14 -0700 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpZ2fNo5HuNs9v1ScuNV2XYIRpWmAAF3FYg In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: acsmt356.oracle.com [141.146.40.156] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4AEBEA92.00EB:SCFMA4539814,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Resent-Date: Sat, 31 Oct 2009 04:07:23 -0400 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:32303 Archived-At: > > This sure seems like a bug to me. If not, please tell me what the > > problem is. > > The problem is that font-lock-keywords's docstring says: > > where MATCHER can be either the regexp to search for, or > the function name to call to make the search (called with > one argument, the limit > > notice that it says "function name" rather than just > "function". So it can't just be a lambda expression, it has > to be a symbol. Ah, thank you. I need to put my reading glasses on! 1. However, the Elisp manual, node `Search-based Fontification' speaks of just `function'. It does not say that it must be a symbol. (Also, the doc string should be clarified, since "function name" is usually a string, the function symbol's `symbol-name'.) `FUNCTION' Find text by calling FUNCTION, and highlight the matches it finds using `font-lock-keyword-face'. When FUNCTION is called, it receives one argument, the limit of the search; it should begin searching at point, and not search beyond the limit. It should return non-`nil' if it succeeds, and set the match data to describe the match that was found. Returning `nil' indicates failure of the search. Fontification will call FUNCTION repeatedly with the same limit, and with point where the previous invocation left it, until FUNCTION fails. On failure, FUNCTION need not reset point in any particular way. And further references to it in this node also refer to it only as "a function". Nowhere does it say that it should be a symbol. So if it must be a symbol, then this is a doc bug. 2. The code I had seems nevertheless to "work", in the sense that it does what I expect (highlights the column). Except that it logs those messages and the performance is terrible. I assume that it is the message logging that degrades the performance (brings Emacs to its knees). Is it indeed a bug that binding `message-log-max' to nil does not suppress the logging here? Or is it simply a doc bug that this limitation of `message-log-max' is not mentioned? 3. I tried using a symbol, as you and the doc string suggested, but I still get the same behavior. I used the same code as before, but with `column-marker-find' redefined as follows, so that it now defines a named function and returns the new function symbol: (defun column-marker-find (col) (let ((fn-symb (intern (format "column-marker-move-to-%d" col)))) (fset `,fn-symb `(lambda (end) (let ((start (point))) (when (> end (point-max)) (setq end (point-max))) (unless (< (current-column) ,col) (forward-line 1)) (when (< (current-column) ,col) (move-to-column ,col)) (while (and (< (current-column) ,col) (< (point) end) (= 0 (+ (forward-line 1) (current-column)))) (move-to-column ,col)) (if (and (= ,col (current-column)) (<= (point) end) (> (point) start)) (progn (set-match-data (list (1- (point)) (point))) t) (goto-char start) nil)))) fn-symb)) Now I see only these 4 messages repeated over and over, instead of the messages citing the atoms in the lambda form that I used previously: Invalid face reference: t Invalid face reference: prepend Invalid face reference: 0 Invalid face reference: column-marker-move-to-36 `column-marker-move-to-36' is the symbol created when I did `M-x column-marker-1'. Its `symbol-function' is this (same as above, with 36 for the column): (lambda (end) (let ((start (point))) (when (> end (point-max)) (setq end (point-max))) (unless (< (current-column) 36) (forward-line 1)) (when (< (current-column) 36) (move-to-column 36)) (while (and (< (current-column) 36) (< (point) end) (= 0 (+ (forward-line 1) (current-column)))) (move-to-column 36)) (if (and (= 36 (current-column)) (<= (point) end) (> (point) start)) (progn (set-match-data (list (1- (point)) (point))) t) (goto-char start) nil))) The value of variable `column-marker-1' is now this list, which should be OK, IIUC: ((column-marker-move-to-36 (0 column-marker-1 prepend t))) And that is therefore also the relevant portion of `font-lock-keywords'. What am I missing? 4. Also, the full value of `font-lock-keywords' does in fact have lambda forms in some of its keyword patterns, but they do not come from this code. They are present even without it. This, for example: ((lambda (bound) (catch 'found (while (re-search-forward "\\(\\\\\\\\\\)\\(?:\\(\\\\\\\\\\)\\|\\((\\(?:\\?:\\)?\\|[|)]\\)\\)" bound t) (unless (match-beginning 2) (let ((face (get-text-property (1- (point)) 'face))) (when (or (and (listp face) (memq 'font-lock-string-face face)) (eq 'font-lock-string-face face)) (throw 'found t))))))) (1 'font-lock-regexp-grouping-backslash prepend) (3 'font-lock-regexp-grouping-construct prepend)) Dunno where that comes from - perhaps from the font-lock machinery itself. In any case, that lambda form does not seem to be causing any `Invalid face reference' messages to be logged. So I still don't understand, and I still haven't found the right way to code this, so that I don't get the error messages. Please advise.