From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Mauger Newsgroups: gmane.emacs.devel Subject: Re: org-mode and mode hooks. Date: Tue, 31 May 2005 11:25:59 -0700 (PDT) Message-ID: <20050531182559.67552.qmail@web60312.mail.yahoo.com> References: <200505271913.j4RJDNE07279@raven.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1117564103 10388 80.91.229.2 (31 May 2005 18:28:23 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 31 May 2005 18:28:23 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 31 20:28:12 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DdBSf-0006yX-37 for ged-emacs-devel@m.gmane.org; Tue, 31 May 2005 20:27:33 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DdBXn-0001wL-G7 for ged-emacs-devel@m.gmane.org; Tue, 31 May 2005 14:32:51 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DdBXR-0001tG-9v for emacs-devel@gnu.org; Tue, 31 May 2005 14:32:29 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DdBXO-0001s2-Im for emacs-devel@gnu.org; Tue, 31 May 2005 14:32:26 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DdBXO-0001qZ-AI for emacs-devel@gnu.org; Tue, 31 May 2005 14:32:26 -0400 Original-Received: from [209.73.178.135] (helo=web60312.mail.yahoo.com) by monty-python.gnu.org with smtp (Exim 4.34) id 1DdBSy-0001Dv-Ja for emacs-devel@gnu.org; Tue, 31 May 2005 14:27:52 -0400 Original-Received: (qmail 67554 invoked by uid 60001); 31 May 2005 18:25:59 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=fYotWI7j1sUMCyIpfqWB/m4Ve1J5VHx6pqaOENHqd/nM+63j+0xaBBkBdW/5GVo0ZIQD8ylEjsldj5I6FYe04hbs5BMHdmqdujtE4m9GGNX25RUTOt+evn0yJ2NKcQ7H1fP++ZoOUb3137zpoV/vQdeI5W0QPidToWppHi1bx1U= ; Original-Received: from [158.171.31.11] by web60312.mail.yahoo.com via HTTP; Tue, 31 May 2005 11:25:59 PDT Original-To: Luc Teirlinck In-Reply-To: <200505271913.j4RJDNE07279@raven.dms.auburn.edu> 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:37959 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:37959 --- Luc Teirlinck wrote: > Both Stefan and me might have partially misunderstood your problem. > That's okay, I've only understood about 2% of this whole thread. :) > `sql-interactive-mode' calls comint-mode without enclosing it in a > delay-mode-hooks form, as it should. To standardize your mode, you > should either define it using `define-derived-mode' (see > `(elisp)Derived > Modes') or read `(elisp)Mode Hooks'. > I've added the `delay-mode-hooks' to the code, so this should be correct going forward. I inherited this mode so I'm still grasping some of it's inner workings. In fact, it hasn't been `sql-interactive-mode' that has had the font-lock problems. The font-lock setup needed in sql-interactive-mode is known when the mode starts, so it can be setup during initialization of the mode. I also verified that sql-interactive-mode does not enable font-lock-mode. It may flip it off and on (after killing font-lock-set-defaults, to get it to reinitialize), iff it is already turned on. The other mode in sql.el is `sql-mode' which is designed to provide editting support of sql scripts is where font-lock has been a challenge. This is not a derived mode so that is not the cause. The need here is to change the keyword rules based upon a local variable section setting or a menu selection. I can easily recalculate the font-lock-defaults needed, the problem was getting font-lock to refresh its internal configuration based on new font-lock-defaults settings. My suggestion to use `font-lock-defontify' was the result of several late nite debugging sessions about six months ago. It seems to no longer be necessary. Stefan's suggestion to kill `font-lock-set-keywords' was already in place but it didn't seem to have a visual impact unless I called `font-lock-defontify'. > The reason why you need `font-lock-defontify' is because I believe (I > did not check this in detail) that all comint uses font-lock for is > font-lock-face, which is exactly what `font-lock-defontify' undoes. > My patches do not try to mend this because most comint derived modes > probably _want_ to keep comint's font-lock-face defaults. > > After standardizing your mode, you _maybe_ might still have to run > font-lock-defontify to remove comint's font-lock-face properties. > (I did not study your code in detail, nor am I completely sure about > what your exact problem is.) > I think sql.el is now properly behaving in terms of its responsibilities relative to derived and minor modes. I'll continue to test it until changes in this area settle down. I will release the patch once I am comfortable that things are stable again...