emacs-devel
[Top][All Lists]
Advanced

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

Re: font-lock-syntactic-keywords obsolet?


From: Dmitry Gutov
Subject: Re: font-lock-syntactic-keywords obsolet?
Date: Mon, 20 Jun 2016 19:45:06 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2

On 06/20/2016 06:25 PM, Alan Mackenzie wrote:

I hold simplicity to be an admirable thing to aim for.  KISS.

Too bad you have to work on CC Mode, then.

Since when has ad hoc calling of high level code from primitives been
"simple and sensible design"?  You'll note that the CC Mode way simply
doesn't need this.

Emacs low-level code runs quite a few hooks already, which are implemented in Lisp. You'll also note that the whole Lisp runtime is called from low-level code.

And I say to you quite openly, the continual niggling and nagging I've
been getting over the past months and years to adapt CC Mode to an
way of dealing with text properties I hold to be inferior has got tiring
and draining.  I'd be most obliged if you would stop doing this.

I wouldn't be in that discussion (or the ones like it) if you just stayed inside CC Mode and didn't try to push new abstractions, poorly designed and duplicating what syntax.el already does, into Emacs core.

If things had been as you suggest, quite likely I would have come up
with something a bit like syntax-propertize-function, though maybe not
very much like it.

Things are like I say. Maybe not quite for CC Mode, but they are for many languages around it.

You could try adding kludges to that, but ultimately, if you want the
file to always be up-to-date in its entirety, eagerly, you're forced to
make many operations slower than they have to be.

If you still think this is true, and can demonstrate this with a test
case, I will have a look at it and attempt to fix it.

I believe I explained the problem quite clearly. But if you're asking for a test case for CC Mode, I don't care for it.

This discussion is about general facilities, after all.

The shortcuts available to CC Mode aren't something all language modes
can use, so syntax-propertization through before/after-change-functions
cannot become the standard. s-p-f can, on the other hand, and already is.

I'd be interested to hear of some Mode where such shortcuts, as you call
them, aren't available.

ruby-mode, for instance. And, like already pointed out, any language where (these requirements are sufficient, but not all necessary):

- Double-quoted strings are allowed to span multiple lines.
- Syntax is complex enough that we need to use the syntax-table property.
- Whether a character gets a syntax-property applied, depends on whether it's inside a string or comment, among other things.

Imagine a language with multiline strings (you can call it "Ruby", or,
maybe, "Emacs Lisp"), and a big file that contains at least one string
per every ten lines. The user goes to the first string and removes its
closing delimiter.

What's your after-change-function going to do?

Whatever is needed.  Sorry, but the question is too vague.  Emacs Lisp
Mode, as far as I know doesn't have its own a-c-f, so the answer would
be "nothing".  I don't know Ruby Mode.

Why don't you do us all a favor and educate yourself about other languages and language modes before arguing that before/after-change-functions can be a general solution as-is?

The point here is that, mostly, strings don't require s-t text
properties.

Some don't, some do. Heredoc strings do.

But text outside of strings often does need text properties. And their application depends on whether given text is inside a string.

If the s-t props aren't "local", then maybe the
syntax-propertize-function approach is a good one.  I haven't had any
reason to think this through.

The zillion email messages on the subject still haven't encouraged you?

On non-"local" syntax table text properties?

On syntax-ppss. Participating in discussions about a subject is usually a good reason to educate themselves about it. For most people, at least.

I don't recall seeing any
discussion of this, except for the one we're now having.  If I've
forgotten it, or missed it, you could perhaps point it out to me.

Non-locality is one of the obvious reasons for syntax-propertize's design, the way that syntax-table application is performed lazily.

Maybe if you haven't been busy writing shallow critique and asked questions instead, we'd gave gotten to this a lot sooner.

Somebody (either you or Stefan) opined
that ALL s-t properties are, in practice, "local".

You're misremembering.

It must have been somebody else, then.  Are you aware of any non-"local"
use of syntax table text properties?

Yes. And I've been telling you about them for the last several messages.



reply via email to

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