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: Mon, 16 Mar 2015 21:26:57 +0100 Message-ID: <877fug8z8u.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1426537640 26968 80.91.229.3 (16 Mar 2015 20:27:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 16 Mar 2015 20:27:20 +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 Mon Mar 16 21:27:11 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 1YXbbS-0001hJ-Cj for ged-emacs-devel@m.gmane.org; Mon, 16 Mar 2015 21:27:10 +0100 Original-Received: from localhost ([::1]:51536 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YXbbR-0006L9-I8 for ged-emacs-devel@m.gmane.org; Mon, 16 Mar 2015 16:27:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50593) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YXbbO-00066S-0B for emacs-devel@gnu.org; Mon, 16 Mar 2015 16:27:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YXbbJ-0002Kd-V8 for emacs-devel@gnu.org; Mon, 16 Mar 2015 16:27:05 -0400 Original-Received: from out3-smtp.messagingengine.com ([66.111.4.27]:55773) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YXbbJ-0002KZ-RH for emacs-devel@gnu.org; Mon, 16 Mar 2015 16:27:01 -0400 Original-Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 6D199212B4 for ; Mon, 16 Mar 2015 16:26:59 -0400 (EDT) Original-Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Mon, 16 Mar 2015 16:27:01 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:from:to:cc:subject:references :date:in-reply-to:message-id:mime-version:content-type; s= smtpout; bh=ooG0bHLFe/JAmPYkbvP/NHR5NJM=; b=ut3lp4OgmzMP27HHDXM7 tsDC0ifjnxEK2vL3nh7Ex1G07HUWOtbTn+ErWJSug7VkdUKZjEv8kAyjazKb5rf5 z+FO2DfTNi49msAtKmEehunTkrUjtgASSePDPL1lwpJQjpSUC0gIOXSrt8t1WFJs ZqQ2zDkcTD10b8Xyq11LEgI= X-Sasl-enc: DHCcLRBxmzMHvqX1YEVJbURRv/VX+zTU0dARnO3EyvIn 1426537620 Original-Received: from thinkpad-t440p (unknown [2.161.11.91]) by mail.messagingengine.com (Postfix) with ESMTPA id 3A957C002A2; Mon, 16 Mar 2015 16:27:00 -0400 (EDT) Mail-Followup-To: Stefan Monnier , Daniel Colascione , Artur Malabarba , emacs-devel In-Reply-To: (Stefan Monnier's message of "Mon, 16 Mar 2015 13:31:48 -0400") User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 66.111.4.27 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:183928 Archived-At: Stefan Monnier writes: >> using Daniel's suggestion. > > I like the "big optimized regexp" better than the "dynamic lookup via > intern-soft" (should make for more efficient font-locking, tho I have > no idea if that really proves faster in practice and even less of an > idea if the difference would be measurable). I've tried it on the 18.000 LOC vhdl-mode.el. --8<---------------cut here---------------start------------->8--- ;; That's the intern-soft variant (defun font-lock-benchmark () (interactive) (message "Benchmark: %s" (benchmark-run-compiled 30 (goto-char (point-min)) (while (lisp--el-match-keyword (point-max)))))) (defconst macro-rx (concat "(" (let (macros) (mapatoms (lambda (a) (when (or (special-form-p a) (macrop a)) (push (symbol-name a) macros)))) (regexp-opt macros t)) "\\_>")) ;; That's the optimized-regexp variant (defun font-lock-benchmark2 () (interactive) (message "Benchmark: %s" (benchmark-run-compiled 30 (goto-char (point-min)) (while (re-search-forward macro-rx nil t) (match-string 1))))) --8<---------------cut here---------------end--------------->8--- Indeed, the variant with the optimized regexp is more than twice as fast as the intern-soft approach. But both variants are so fast that there's no observable difference. > Also, that loses the "update existing buffers after macro definition", > so it's far from "clearly better" w.r.t end-user behavior (and the > relative simplicity advantage will probably end up vanishing if we try > to fill those kinds of differences). Yes, that's what I've said. The reason why I haven't implemented it yet is that I'm not sure where to add the relevant code. With the intern-soft approach, we can basically adjust fontification as soon as a new macro is defined or evaluated using C-c C-e because it's cheap (in contrast to updating existing buffers only when a file is loaded). But of course if a file defines 100 macros, I don't want 100 updates of existing elisp buffers. Any suggestions how/where to update existing buffers? I can imagine that `defmacro' starts or resets some idle timer which updates existing buffers. But having a byte-run -> lisp-mode dependency just seems wrong. > But it's largely a question of bikeshed color, so if you all prefer the > intern-soft approach, go for it. Currently it's mostly Daniel vs. you, so let's wait for some more opinions. >> (2) adding (declare (no-font-lock-keyword t)) to all function-like >> macros we have (e.g., push, pushnew) > > push and pushnew aren't function-like, so they *should* be highlighted > as keywords, I think. I guess they are not function-like because they deal with generalized variables, right? Bye, Tassilo