[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: font-lock-syntactic-keywords obsolet?
From: |
Alan Mackenzie |
Subject: |
Re: font-lock-syntactic-keywords obsolet? |
Date: |
Mon, 20 Jun 2016 10:58:50 +0000 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
Hello, Dmitry.
On Sun, Jun 19, 2016 at 08:55:52PM +0300, Dmitry Gutov wrote:
> On 06/19/2016 08:15 PM, Alan Mackenzie wrote:
[ .... ]
> > Consider the following non-unusual case. In C++ Mode we have nested
> > template delimiters, thusly:
> > A B C D
> > < < > >
> > They each have parentheses syntax-table text properties such that A
> > matches D and B matches C. You can, for example put point at A, do
> > C-M-n, and you will get to after D.
> > Suppose you delete the < at A, and move point to D. What will now
> > happen if you do C-M-p?
> Scan error?
No. In the current C++ Mode, after-change functions remove the
syntax-table text property from D, ensuring template delimiters balance
always.
> > With a syntax-propertize-function instead of the current
> > before/after-change-functions, I simply can't picture what would happen.
> The same.
> a) By the time you move point to D, font-lock has most likely run, ....
only when font-lock is enabled. What about when it's not enabled?
You seem to be advocating that CC Mode should lose its deterministic text
property handling and replace it by a "hope it's OK" non-deterministic
handling. You can understand me not wanting to do this.
> .... and the current visible area of the buffer is already
> syntax-propertized (this is how this problem was solved in Emacs <25).
There's no guarantee that the matching template delimiter for any given
delimiter is on the screen. It might be after the screen, it might be
before it.
> b) In addition to that, scan_lists now applies syntax-table properties
> by calling syntax-propertize-function
Yuck! That's the sort of ugly workaround that becomes needed when things
aren't properly thought through from the beginning. In a proper design,
the low level routines in syntax.c wouldn't even know about s-p-function,
and nor should they.
> > Why do we need such a general abstraction, anyway?
> > before/after-change-functions already form a good scheme for applying
> > and removing these properties.
> Because just by the virtue of having before/after-change-functions, we
> can [can't :-] be sure that a given position is syntax-propertized.
In CC Mode that certainty exists. That certainty exists if the
before/after-change-functions are implemented properly.
> The only way we could, without adding additional abstraction, is by
> agreeing that all buffers must be syntax-propertized in their entirety
> after before/after-change-functions run. And that is just too damn wasteful.
How is it wasteful? If the syntax-table properties are all "local", it's
actually an efficient way to do things. You simply have to extend the
(beg end) region to that which might contain pertinent characters, remove
s-t properties in a before-change function, and apply them in an
after-change function. 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. Somebody (either you or Stefan) opined
that ALL s-t properties are, in practice, "local".
> > Changing CC Mode to use syntax-propertize-function would require a
> > substantial amount of design work, assuming such were possible. There
> > doesn't seem to be a good reason to do this.
> One reason would be for you to get a handle on what it does, and the
> design benefit that follow.
The current CC Mode before/after-change-function design has been
carefully thought out. I'm not convinced that's the case for the
syntax-propertize-function mechanism.
> Maybe you would discover an even better design along the way, who
> knows.
Maybe. But it's not as though I'm short of things to do.
--
Alan Mackenzie (Nuremberg, Germany).
- Re: font-lock-syntactic-keywords obsolet?, (continued)
- Re: font-lock-syntactic-keywords obsolet?, Alan Mackenzie, 2016/06/19
- Re: font-lock-syntactic-keywords obsolet?, Dmitry Gutov, 2016/06/19
- Re: font-lock-syntactic-keywords obsolet?, Alan Mackenzie, 2016/06/19
- Re: font-lock-syntactic-keywords obsolet?, Dmitry Gutov, 2016/06/19
- Re: font-lock-syntactic-keywords obsolet?, Dmitry Gutov, 2016/06/19
- Re: font-lock-syntactic-keywords obsolet?, Alan Mackenzie, 2016/06/20
- Re: font-lock-syntactic-keywords obsolet?, Dmitry Gutov, 2016/06/20
- Re: font-lock-syntactic-keywords obsolet?, Alan Mackenzie, 2016/06/20
- Re: font-lock-syntactic-keywords obsolet?, Dmitry Gutov, 2016/06/20
- Re: font-lock-syntactic-keywords obsolet?, Stefan Monnier, 2016/06/20
- Re: font-lock-syntactic-keywords obsolet?,
Alan Mackenzie <=
- Re: font-lock-syntactic-keywords obsolet?, Andreas Röhler, 2016/06/20
- Re: font-lock-syntactic-keywords obsolet?, Dmitry Gutov, 2016/06/20
- Re: font-lock-syntactic-keywords obsolet?, Noam Postavsky, 2016/06/20
- Re: font-lock-syntactic-keywords obsolet?, Dmitry Gutov, 2016/06/20
- Re: font-lock-syntactic-keywords obsolet?, Noam Postavsky, 2016/06/20
- Re: font-lock-syntactic-keywords obsolet?, Dmitry Gutov, 2016/06/20
- Re: font-lock-syntactic-keywords obsolet?, Alan Mackenzie, 2016/06/20
- Re: font-lock-syntactic-keywords obsolet?, Dmitry Gutov, 2016/06/20
- Re: font-lock-syntactic-keywords obsolet?, Alan Mackenzie, 2016/06/20
- Re: font-lock-syntactic-keywords obsolet?, Dmitry Gutov, 2016/06/20