From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tassilo Horn Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master 51e7e46: Font-lock elisp macros/special forms dynamically Date: Wed, 18 Mar 2015 08:17:45 +0100 Message-ID: <87sid2epuu.fsf@gnu.org> References: <20150315082509.21193.18465@vcs.savannah.gnu.org> <55054CE9.6010702@dancol.org> <87bnjt4e00.fsf@gnu.org> <550681E3.7080407@dancol.org> <871tkpov7p.fsf@gnu.org> <877fug8z8u.fsf@gnu.org> <55073F67.20809@dancol.org> <87k2yg55jl.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1426663089 11075 80.91.229.3 (18 Mar 2015 07:18:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 18 Mar 2015 07:18:09 +0000 (UTC) Cc: Daniel Colascione , Artur Malabarba , emacs-devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 18 08:18:00 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YY8Ep-0001Fi-EG for ged-emacs-devel@m.gmane.org; Wed, 18 Mar 2015 08:17:59 +0100 Original-Received: from localhost ([::1]:59473 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YY8Eo-0004Sr-O2 for ged-emacs-devel@m.gmane.org; Wed, 18 Mar 2015 03:17:58 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48683) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YY8Ek-0004SU-Dw for emacs-devel@gnu.org; Wed, 18 Mar 2015 03:17:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YY8Ef-0007Ds-NM for emacs-devel@gnu.org; Wed, 18 Mar 2015 03:17:54 -0400 Original-Received: from deliver.uni-koblenz.de ([141.26.64.15]:44748) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YY8Ef-0007Dg-Hg for emacs-devel@gnu.org; Wed, 18 Mar 2015 03:17:49 -0400 Original-Received: from thinkpad-t440p (dhcp132.uni-koblenz.de [141.26.71.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by deliver.uni-koblenz.de (Postfix) with ESMTPSA id 635811A8013; Wed, 18 Mar 2015 08:17:46 +0100 (CET) Mail-Followup-To: Stefan Monnier , Daniel Colascione , Artur Malabarba , emacs-devel In-Reply-To: (Stefan Monnier's message of "Tue, 17 Mar 2015 12:34:03 -0400") User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 141.26.64.15 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:183983 Archived-At: Stefan Monnier writes: >>>> Isn't font-lock-flush supposed to be cheap? >>> If you use jit-lock-mode, yes. If not, no. >> Using it is the default. Is there a good reason a user might have >> disabled it for elisp buffers? > > There ideally shouldn't be a good reason, no. It can be very useful > while debugging font-lock-keywords, and things like that, but for > "normal" use, jit-lock-mode should always be used in Elisp buffers. Ok. I just tried it anyway, and with jit-lock disabled, `font-lock-flush' does nothing, e.g., the buffer portion you have already scrolled through is still fontified as it has been before but the yet "unknown" portions are and stay in the default face when scrolling to them. So it seems like in non-jit-locked buffers we'd actually need to call f-l-flush followed by f-l-ensure. But OTOH, when someone turns off jit-lock to debug fontification, she might not like refreshed from the outside so that behavior could be seen as justified there... >> If no one objects, I'm going to install the patch below anytime soon >> when the master branch bootstraps again without >> Eager macro-expansion failure: (void-function cl-every) > > Isn't this fixed already (at least, the cl-every I introduced has > disappeared as a side-effect of a subsequent change)? Yes, yes, its fixed. I've committed and pushed my last patch (with some fixes since the posted version) as 9fdc166. If no one comes up with a (semi-)automated way of identifying function-like macros, I'll go check the ~1300 macros in emacs manually. For that, do we have clear criteria when we consider a macro function-like? Here's my list so far: - function-like: + has no arguments + just there to save a funcall (ad-get-advice-info-macro, shadow-cluster-name) Shouldn't those be defsubsts instead of macros? - not function-like: + is a control structure (when, when-let, cl-loop,...) + modifies places (push, pushnew, setf, ...) + defines something (def*, define-*) + sets up some environment (with-*, save-*) + error handling (ignore-errors, condition-case) + anaphora Bye, Tassilo