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: First fontification of a buffer happens before font lock is fully initialised. Date: Sun, 05 Feb 2012 20:39:00 -0500 Message-ID: References: <20120125124804.GB3638@acm.acm> <20120125182651.GA3624@acm.acm> <20120204120319.GC3347@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1328492350 31447 80.91.229.3 (6 Feb 2012 01:39:10 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 6 Feb 2012 01:39:10 +0000 (UTC) Cc: Hannu Koivisto , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 06 02:39:09 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RuDXw-0002CT-KA for ged-emacs-devel@m.gmane.org; Mon, 06 Feb 2012 02:39:08 +0100 Original-Received: from localhost ([::1]:59972 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RuDXv-0005pw-Vu for ged-emacs-devel@m.gmane.org; Sun, 05 Feb 2012 20:39:07 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:55720) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RuDXs-0005pg-RD for emacs-devel@gnu.org; Sun, 05 Feb 2012 20:39:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RuDXq-0005Rx-IP for emacs-devel@gnu.org; Sun, 05 Feb 2012 20:39:04 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:49144) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RuDXq-0005Rt-G3 for emacs-devel@gnu.org; Sun, 05 Feb 2012 20:39:02 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAA4vL09MCqD0/2dsb2JhbABDrzKBBoFyAQEEAVYjEAsOJhIUGA0kiA+4TIwOEgICAwYCBAIBBAICDAYNhB4BBAQYAgSDOQSIRJsDhFo X-IronPort-AV: E=Sophos;i="4.73,367,1325480400"; d="scan'208";a="161398518" Original-Received: from 76-10-160-244.dsl.teksavvy.com (HELO pastel.home) ([76.10.160.244]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 05 Feb 2012 20:39:01 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 9110F58C8C; Sun, 5 Feb 2012 20:39:00 -0500 (EST) In-Reply-To: <20120204120319.GC3347@acm.acm> (Alan Mackenzie's message of "Sat, 4 Feb 2012 12:03:19 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:148223 Archived-At: >> Yes, I agree. This was the behavior in Emacs-20, and is also the >> behavior with jit-lock (i.e. the default behavior). I'm not sure what's >> the best way to get that result, tho: adding yet-another keyword to >> define-minor-mode is something I'd rather avoid. > I can only see one other way to deal with this: that is to write > `font-lock-mode' explicitly; or rather, expand the macro by hand, tidy it > up, and move the `run-hooks'. Moving away from define-minor-mode is also something I'd rather avoid (so we don't have to update font-lock-mode every time we change define-minor-mode). Some other thoughts: - use some trick to delay the fontification to after the minor-mode hook is run (e.g. add to post-command-hook or something like that). post-command-hook is not a good choice and I can't think of much better, so maybe this is out. - maybe it's OK to add yet another argument to define-minor-mode. Note that an arg that says "turn off this standard thingy" (as in :no-hook) is out of the question, since a large part of the reason why we have define-minor-mode is to try and auto-enforce the coding conventions of minor modes. But maybe we can have an :after-hook. Some major modes would also appreciate such a feature, so maybe this same arg can be added to both define-minor-mode and define-derived-mode. Stefan