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 00:10:27 -0700 Message-ID: <550681E3.7080407@dancol.org> References: <20150315082509.21193.18465@vcs.savannah.gnu.org> <55054CE9.6010702@dancol.org> <87bnjt4e00.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="16dDdaIf650RefE8cDDRMVjJBQWwSFhiK" X-Trace: ger.gmane.org 1426489846 10821 80.91.229.3 (16 Mar 2015 07:10:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 16 Mar 2015 07:10:46 +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 08:10:44 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 1YXPAg-00034p-Vi for ged-emacs-devel@m.gmane.org; Mon, 16 Mar 2015 08:10:43 +0100 Original-Received: from localhost ([::1]:47610 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YXPAg-0002sy-89 for ged-emacs-devel@m.gmane.org; Mon, 16 Mar 2015 03:10:42 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36508) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YXPAb-0002rH-Jw for emacs-devel@gnu.org; Mon, 16 Mar 2015 03:10:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YXPAa-00073h-OD for emacs-devel@gnu.org; Mon, 16 Mar 2015 03:10:37 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:53782) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YXPAa-00073a-6w for emacs-devel@gnu.org; Mon, 16 Mar 2015 03:10:36 -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=U1ZQOHw2Lm4Oqrgv/zQCedFUQVPWSWFxX9mhvqBTb2o=; b=RZ66vGFZwkgpslIpRi5MLnE+AKa74NI7By6fOBRMFiw2sDacWc95Ms83R7jhgAcKFsU0WQ/kApKj7nrEEp1O/6V0tlYrFMo0ftjUb5VjIb780+TXFGYmTCE20TLKpxN49SapqrKvaB/LX8abrUyawGzA6qHHzAK/VficmEACDkbOQGzI+UfQ7IZNXC5gXcAfirBppMoPbgMnjXMQ4F/EeYT+NJ3zJuHjeGuIB6O0b+tD8yEgVF8784ivPEaN7wjIA4HXc0bZ1Ui/jB3a0RAf12UVPdf+ylpz794VOT185pOPRevcS4mI24pwuS0eIBHNdln0qYCYyGEog1Lwl4iv6Q==; Original-Received: from [2620:10d:c081:1101:2ab2:bdff:fe1c:db58] by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1YXPAY-0002wl-1s; Mon, 16 Mar 2015 00:10:34 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 In-Reply-To: <87bnjt4e00.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:183896 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --16dDdaIf650RefE8cDDRMVjJBQWwSFhiK Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 03/16/2015 12:07 AM, Tassilo Horn wrote: > Stefan Monnier writes: >=20 >>> Finally, I'm positively surprised at how fast the update function is.= >>> I would have expected some lag, but haven't found any (even though I'= m >>> looking). >> >> Loading Elisp files should be fairly rare. But there might be cases >> where it can be done repeatedly, but if/when faced with such a situati= on >> we should be able to handle it efficiently e.g. by checking the >> load-history (make sure the file did include some definitions before w= e >> bother to scan symbols and rebuild the regexp) since such "run-time >> loading" probably won't define new functions. >=20 > Like so? Instead of doing it this way, why not make a font-lock matcher that looks at *every* initial sexp atom, calls intern-soft on it, and applies a face that depends on properties of the found symbol? This way, we'd update fontification not only after load, but also after eval-defun, and it'd be easy to make a `declare'-form that provided for exceptions from the general rule. cc-mode uses a system like this for keywords, and I think it's what Stefan was talking about earlier. --16dDdaIf650RefE8cDDRMVjJBQWwSFhiK 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 iQIcBAEBCAAGBQJVBoHjAAoJEN4WImmbpWBlEh0P/3gkEFKijB0WQDvlZzi3q11M R5KtrxZ/jwA622B/X02Cn68CSfO2eGnw8M2e/sutGFGs3EciRQ+IFq0zfL0lNEDJ Ql66VXrXw22dTkEEjalFz3BpARC+90KPqPVVb8O42HsngynUJh79fZBUu3IhZcpA MI6hzBBKUIxui0EIFn4ANlr8SOiyulCmNSitKaGuW7NYq9j7F20yplLcl7cQ7ujo Yc7OLga4tK/AJdNdd3FgrmNz8I0tEVzpo23+cJeCVych3nZpPnpj6EwGyufF/it0 Y/4lEbA6FgIAuvDx+1op4o0V+bLxuFcTi2LCmvFbZNgXu3c0B4veenkBaJ7ISd9H tUh8tYCj9V8yWCaJxZCvTPBiRgWEcxgbt0UhNPUyWsXF+NhK/JSRhV4zJc7tWruS fvMu60L4u5mKXjfAiGYW7W/NXvFxEf6l0BlgL2TOgCma96h2CVBb0bEtcnVF+XlQ xm6ZBq5g8RIhpl715UYZCdxdNWS6pVhES0IzFGZY/OVFb8XNwx46AUJgvOMmxV2n 9YNWCQG0MsTZs4lj4IFGQ5sdaUnCNYc3JrnJZdLDhHvvb+vYssfuZMpmIoBO06AE GhHaFC91b6CMN0C3sICMjJkbboUQJh0CIVvS3XllhjCE4TPSr8cpqXeub2ylXfJ3 QIjzglMh/erUKvlFFjPB =SG/m -----END PGP SIGNATURE----- --16dDdaIf650RefE8cDDRMVjJBQWwSFhiK--