From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.help Subject: Re: XKCD/541 compliance, anyone? Date: Thu, 01 Jan 2015 23:07:59 -0500 Message-ID: References: <8761drazec.fsf@wmi.amu.edu.pl> <87k318npmf.fsf@wmi.amu.edu.pl> <87387udvr8.fsf@wmi.amu.edu.pl> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1420171725 15981 80.91.229.3 (2 Jan 2015 04:08:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 2 Jan 2015 04:08:45 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Jan 02 05:08:38 2015 Return-path: Envelope-to: geh-help-gnu-emacs@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 1Y6tXQ-0002R0-Pb for geh-help-gnu-emacs@m.gmane.org; Fri, 02 Jan 2015 05:08:36 +0100 Original-Received: from localhost ([::1]:50258 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y6tXP-0003p6-Vv for geh-help-gnu-emacs@m.gmane.org; Thu, 01 Jan 2015 23:08:35 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51414) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y6tXF-0003op-04 for help-gnu-emacs@gnu.org; Thu, 01 Jan 2015 23:08:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y6tX9-0006Ds-KY for help-gnu-emacs@gnu.org; Thu, 01 Jan 2015 23:08:24 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:55971) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y6tX9-0006DP-E4 for help-gnu-emacs@gnu.org; Thu, 01 Jan 2015 23:08:19 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Y6tX6-0002CV-0s for help-gnu-emacs@gnu.org; Fri, 02 Jan 2015 05:08:16 +0100 Original-Received: from 192.81.14.21 ([192.81.14.21]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 02 Jan 2015 05:08:16 +0100 Original-Received: from monnier by 192.81.14.21 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 02 Jan 2015 05:08:16 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 65 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 192.81.14.21 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) Cancel-Lock: sha1:QCuOudbo72AsjDDdMuzA/HWjN8s= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:101828 Archived-At: >> Beware: syntax-propertize-function might already be in use, in which >> case you should probably use add-function to combine the two. > Hm. My Emacs (24.3) doesn't have anything called add-function. I > checked on the interwebs, and it seems it's part of the new advice > system. I'll have to upgrade finally. Tho you probably only need this syntax-propertize-smileys thingy for modes which don't use syntax-propertize-function yet, so maybe add-function is not really necessary. > My question: wouldn't it be reasonable to change > syntax-propertize-function into a /list/ of functions? At this point, it wouldn't be reasonable, no: add-function works as well already. Also, combining various functions there doesn't work quite as easily as it sounds. For example, in your case, it works OK to put your function before the major mode's function, but doing it the other way around wouldn't always work right. For more general syntax-propertize-functions, you can't just run them in turn. > I checked it, and I see it's even better, it will make it buffer-local. > Again: very handy. BTW: do I guess correctly that the reason that > parse-sexp-lookup-properties is nil by default (and the reason for its > existence in the first place) is performance issues? If yes, is the > difference between having it nil and t substantial on modern hardware? No, the difference is negligible. It's a historical left-over. >>> However, it did not work (in text mode); my make-smileys-punctuation >>> seems not even to get called. >> Right, syntax-propertization is done lazily, so if nothing calls >> syntax-propertize, then that's that. Usually the main triggers for >> syntax-propertize are syntax-ppss and font-lock, but neither is likely >> to be used in text-mode. So you'll probably need to arrange for font-lock >> to be enabled *and* for font-lock-keywords-only not to be set to t. > Well, I did not understand everything you wrote here. I guess I will > just have to RTFM; I vaguely remember reading about "lazy font-lock" 15 > years ago, This is unrelated. I used "lazy" in the general sense of "do things as late as possible". >> Probably because font-lock-keywords-only is set to t, so font-lock >> doesn't end up calling syntax-ppss. > Yes it is, though I don't (yet) understand what this means. See above. This has to do with the way font-lock handles strings and comments separately from other highlighting. In message-mode, this special strings-and-comments highlighting is disabled, yet, that's the one that normally triggers syntax-propertize. You could also use something like (defun my-call-syntax-propertize (limit) (syntax-propertize limit) (goto-char limit) nil) (font-lock-add-keywords nil '((my-call-syntax-propertize))) > Thank you so much! My pleasure, Stefan