Re: XKCD/541 compliance, anyone?

[Marcin Borkowski <mbork@wmi.amu.edu.pl>]

On 2015-01-02, at 05:07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

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

Not sure if I understand.

I don't need my smileys thing for programming modes – here, smileys
should appear only in strings/comments, and they don't do any harm
there.  Where I need it is mainly text, org, message and (la)tex modes.

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

OK.

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

That's what I thought, more or less.

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

I see.

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

Again: I'll have to read the manual.

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

This idea might come in handy, since the next step is to mark smileys
with gray;-).

>> Thank you so much!
>
> My pleasure,
>
>         Stefan

Thanks again!

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University