help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: XKCD/541 compliance, anyone?


From: Stefan Monnier
Subject: Re: XKCD/541 compliance, anyone?
Date: Thu, 01 Jan 2015 23:07:59 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

>> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]