From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: First fontification of a buffer happens before font lock is fully initialised. Date: Tue, 7 Feb 2012 10:10:08 +0000 Message-ID: <20120207101008.GB3314@acm.acm> 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; charset=us-ascii X-Trace: dough.gmane.org 1328609441 28224 80.91.229.3 (7 Feb 2012 10:10:41 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 7 Feb 2012 10:10:41 +0000 (UTC) Cc: Hannu Koivisto , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 07 11:10:38 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 1Rui0T-00054i-Bp for ged-emacs-devel@m.gmane.org; Tue, 07 Feb 2012 11:10:37 +0100 Original-Received: from localhost ([::1]:39036 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rui0S-0001lW-Id for ged-emacs-devel@m.gmane.org; Tue, 07 Feb 2012 05:10:36 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:43907) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rui0O-0001lR-Vo for emacs-devel@gnu.org; Tue, 07 Feb 2012 05:10:34 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rui0J-0007FC-4U for emacs-devel@gnu.org; Tue, 07 Feb 2012 05:10:32 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:52756 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rui0I-0007Er-R6 for emacs-devel@gnu.org; Tue, 07 Feb 2012 05:10:27 -0500 Original-Received: (qmail 70610 invoked by uid 3782); 7 Feb 2012 10:10:24 -0000 Original-Received: from acm.muc.de (pD95199DD.dip.t-dialin.net [217.81.153.221]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 07 Feb 2012 11:10:19 +0100 Original-Received: (qmail 4198 invoked by uid 1000); 7 Feb 2012 10:10:08 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 193.149.48.1 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:148296 Archived-At: Hello, Stefan. On Sun, Feb 05, 2012 at 08:39:00PM -0500, Stefan Monnier wrote: > >> 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). OK. > 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. post-command-hook _is_ ugly, and we don't want one-time code running in it. > - maybe it's OK to add yet another argument to define-minor-mode. define-minor-mode is insufficiently general, so something has to give. > 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. Can we not trust the good taste and sense of hackers generally? We can certainly trust the Emacs developers. > 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. Or, perhaps, even (defmacro run-hooks-here () ...), which would preserve the order of the initialisation forms in the mode. But I'd be happy enough with :after-hook. Would you like me to implement it? > Stefan -- Alan Mackenzie (Nuremberg, Germany).