From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Patch for sql.el Date: 04 May 2004 17:59:49 -0400 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <20040504025902.840.qmail@web60301.mail.yahoo.com> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1083709450 17345 80.91.224.253 (4 May 2004 22:24:10 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 May 2004 22:24:10 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed May 05 00:24:03 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BL8KZ-0004q9-00 for ; Wed, 05 May 2004 00:24:03 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BL8KY-0003Ns-00 for ; Wed, 05 May 2004 00:24:03 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BL7yV-0003et-0n for emacs-devel@quimby.gnus.org; Tue, 04 May 2004 18:01:15 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BL7xn-0003V4-4w for emacs-devel@gnu.org; Tue, 04 May 2004 18:00:31 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BL7xD-0003KL-Oi for emacs-devel@gnu.org; Tue, 04 May 2004 18:00:26 -0400 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BL7xD-0003Jq-7R for emacs-devel@gnu.org; Tue, 04 May 2004 17:59:55 -0400 Original-Received: from asado.iro.umontreal.ca (asado.iro.umontreal.ca [132.204.24.84]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id B397520542; Tue, 4 May 2004 17:59:49 -0400 (EDT) Original-Received: by asado.iro.umontreal.ca (Postfix, from userid 20848) id A1D728C6AE; Tue, 4 May 2004 17:59:49 -0400 (EDT) Original-To: Michael Mauger In-Reply-To: <20040504025902.840.qmail@web60301.mail.yahoo.com> Original-Lines: 47 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 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=-0.001, requis 5, BAYES_44 -0.00) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:22762 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:22762 > I did a little testing and made some adjustments. Sql.el is a little > different from most modes -- the keywords are dependent upon the setting > of a buffer local variable (`sql-product'). It is therefore possible that > the font-lock settings may change after the buffer has been fontified. > I addressed this by setting the variable `font-lock-set-defaults' to nil > when `font-lock-defaults' is changed. If `font-lock-mode' is active, > I call `font-lock-mode-internal' to turn it off and then call it again > to restore font-lock with the new settings. Hmm... that's bad. I guess the "cleanest" way to do it with the current font-lock.el code would be to only put the ANSI patterns on sql-font-lock-keywords and then use font-lock-add-keywords and font-lock-remove-keywords for the product-specific patterns (and call font-lock-fontify-buffer to refresh the buffer). But that does not allow you to play with the syntax-alist property. The problem with the current code is that not only you're using internal font-lock variables and functions, but you end up throwing away keywords that might have been added by a minor-mode (such as smerge-mode). This is an other area of font-lock which is just very unsatisfactory right now. I think most major modes work around this by using a single set of keywords which covers all cases (which of course is only workable if there is no conflict/ambiguity). In the mean time, I installed your patch. Stefan PS: the `Products' menu could be generated dynamically. PPS: BTW, I thought I'd sent you a patch about it, but I must have dreamt it, so here it is finally: clean up the "system-flag" handling in abbrev-table as follows: (unless sql-mode-abbrev-table (define-abbrev-table 'sql-mode-abbrev-table '(("ins" "insert" nil nil t) ("upd" "update" nil nil t) ("del" "delete" nil nil t) ("sel" "select" nil nil t) ("proc" "procedure" nil nil t) ("func" "function" nil nil t) ("cr" "create" nil nil t))))