From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master 51e7e46: Font-lock elisp macros/special forms dynamically Date: Mon, 16 Mar 2015 13:39:03 -0700 Message-ID: <55073F67.20809@dancol.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7SxGVSVkfCtlEdsbC4MkGbTf1xslFJlW6" X-Trace: ger.gmane.org 1426538363 6620 80.91.229.3 (16 Mar 2015 20:39:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 16 Mar 2015 20:39:23 +0000 (UTC) To: Stefan Monnier , Artur Malabarba , emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 16 21:39:22 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 1YXbnF-00022r-Kr for ged-emacs-devel@m.gmane.org; Mon, 16 Mar 2015 21:39:21 +0100 Original-Received: from localhost ([::1]:51576 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YXbnE-0005n8-Tb for ged-emacs-devel@m.gmane.org; Mon, 16 Mar 2015 16:39:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53262) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YXbn7-0005iA-7H for emacs-devel@gnu.org; Mon, 16 Mar 2015 16:39:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YXbn5-0006FW-KS for emacs-devel@gnu.org; Mon, 16 Mar 2015 16:39:13 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:57503) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YXbn5-0006FQ-89 for emacs-devel@gnu.org; Mon, 16 Mar 2015 16:39:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=frwsL1J+fBx927GdY/r2VVCkHmuHAC+BEabTr2754g0=; b=CVH/OSA91eILg4EzSVuwq30Ry1l7TwrTj8EV2Saw9y4Ipo928wBGWw6AC03WkppqhRflNFPAKiY96DQXM9ZpjHOw6z+zTeqmOhG4UtJzajRzTc0nBxwKY/m0foRt66cKsVYt7CZS+66RInFOhog2vCq/BCJvdHIFzoYyQPsKsy7YK3ZtpcGzAHp3BooXq7hLSXLT7/eJd62Uaa0W9YFjWmWI5TmY73WzZ1BG0QCgZ7v8b2rcQsUDnvv+QQ6l6Yr7FsLxOnIZXFsksUFmJ7Wl9kYsTvHc44ARFuf7ydMSjmfo7XIMhP7luq5Mwc+FXXQJvdawXbheMcB2XyuzzolJQg==; Original-Received: from [2620:10d:c083:1004:56ee:75ff:fe20:83dc] by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1YXbn3-0000BA-1S; Mon, 16 Mar 2015 13:39:09 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 In-Reply-To: <877fug8z8u.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:183929 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7SxGVSVkfCtlEdsbC4MkGbTf1xslFJlW6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 03/16/2015 01:26 PM, Tassilo Horn wrote: > Stefan Monnier writes: >=20 >>> 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). >=20 > I've tried it on the 18.000 LOC vhdl-mode.el. >=20 > --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)))))) >=20 > (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)) > "\\_>")) >=20 > ;; 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--- >=20 > Indeed, the variant with the optimized regexp is more than twice as fas= t > as the intern-soft approach. But both variants are so fast that there'= s > no observable difference. >=20 >> 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). >=20 > Yes, that's what I've said. The reason why I haven't implemented it ye= t > 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. >=20 > Any suggestions how/where to update existing buffers? >=20 > I can imagine that `defmacro' starts or resets some idle timer which > updates existing buffers. But having a byte-run -> lisp-mode dependenc= y > just seems wrong. Isn't font-lock-flush supposed to be cheap? Running it a thousand times on byte-run.el only takes 3ms. If that's too expensive, we can ordinarily run font-lock-flush immediately, but during load, bind a variable that defers the call until it's unbound. Maybe something like this around load? (defmacro with-deferred-emacs-lisp-fontification-updates (&rest body) `(let ((inhibit-emacs-lisp-fontification-update t)) ,@body (emacs-lisp-font-lock-flush-all-buffers)) >=20 >> But it's largely a question of bikeshed color, so if you all prefer th= e >> intern-soft approach, go for it. >=20 > Currently it's mostly Daniel vs. you, so let's wait for some more > opinions. >=20 >>> (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. >=20 > I guess they are not function-like because they deal with generalized > variables, right? Right. I'm okay with either opt-in or opt-out behavior. Maybe we can use edebug specs to detect function-like macros in the absence of other information? --7SxGVSVkfCtlEdsbC4MkGbTf1xslFJlW6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJVBz9nAAoJEN4WImmbpWBl7h4QAJCRuFGvmmlM99TPi7PkgPXC I/4wMnKntgQjQLMwO1oxlnOJDdcrQ1pCYECd0fvVofkjbQ57f+axVPX31zfg+8Qu DNsL2aFvTw/7ywG2TawBErIw+DBpNJqWs9ER+UQYS8fg0YUay1sIUDjfqbj3fWO9 iqunexQj+XQEzZi+55bRg6jfJ3Z/XzI0Xh2LFVPfO6qsPi6871OP/4ZD5EcbmTdQ BAZjkL/H/MigUJUuPbshvNsxCuStrLMu3KlbK28quteSTM79R970g/n9tiqpJbYx tlyZWGC7gTDCrirjAxHon+EqSDKqyirM5pIp/22Cn5cult086RrEgnkWQAUQz3SW q2SNx6vQoogiSlSoqoqJw/HsQ8n+XwEgfylZtLLBKExePZfWHDB19RBNNKzBdBYV oGY/AQ8QqdPZZ6izWwoG7CFgEXJ+9ISDO7AD4SBW3ZDe/yFgNz8E4yyXmxTuXFDz tDcxvE4dlu2t5Qhzi3aq4bHfsx5qw/09/bMRruoc7v9zEe6TB5cOMYKsk7y0W2E/ aLw28rlucn6YlLTm4Bl6ZZfJGf+ZzqP1wHO5Ujt/lxMDwyIXvr0aN/nBJbVngL4G yyqSkDBgVd/HHOaeYXItduHigZxjSLo40w6uanSTGNIj0nZ3TuK/GkusO7xFSbWt h4o2SzWkvehyBqfZUv/9 =kF+w -----END PGP SIGNATURE----- --7SxGVSVkfCtlEdsbC4MkGbTf1xslFJlW6--