From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Alan Mackenzie <acm@muc.de>
Cc: emacs-devel@gnu.org
Subject: Re: Syntax-propertize and CC-mode [Was: Further CC-mode changes]
Date: Sun, 14 Sep 2014 00:04:54 -0400 [thread overview]
Message-ID: <jwvy4tmhoad.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <20140913230812.GA3660@acm.acm> (Alan Mackenzie's message of "Sat, 13 Sep 2014 23:08:12 +0000")
> I've separated the discussion on syntax-propertize from the rest,
> because things are threatening to get out of hand.
Important note: I only provided a patch to use syntax-propertize for
awk-mode. This case is much simpler to handle than the C/C++/Java cases
(at least, IIUC, the way you apply syntax-table properties in awk-mode
is easy to map to what syntax-propertize needs).
Using syntax-propertize for C/C++/Java is a whole other project, which
I hope to get to at some point, but I'll need to dig much deeper into
the belly of the beast before I can hope to do that.
> How is the lower limit determined (matching the upper limit POS)?
Syntax-propertize internally keeps track of "up-to-where have properties
been applied", so that it can provide the lower limit.
> At a guess, this is going to be anywhere down to BOB.
That can be, tho usually it's just "the beginning of the last buffer
modification".
> This isn't very lazy. Why doesn't syntax-propertize take TWO
> parameters, BEG and END?
How would you know what is BEG without knowing what other packages
(indent.el, font-lock.el, ...) have already `syntax-propertize'd?
> Looking at the source, syntax-propertize is unoptimised. It will always
> erase the syntax-table properties from the last buffer change onwards, in
> contrast to C++ Mode, which only erases them locally as needed.
syntax-propertize is lazy, but indeed it always assumes pessimistically
that any change to the buffer at POS might cause everything after POS to
be interpreted completely differently and hence require re-propertization.
So far, this has not proved to be problematic in any of the 20 or so
major modes that use syntax-propertize.
> There is surely an opportunity for better customisation here.
Yes, we could spice up syntax.el so that you can set some properties and
explain when modifications in previous text don't invalidate them.
We haven't seen a need for it so far.
> That is not true. I need to know that syntax-propertize would nullify
> C++/Java Modes' careful optimisations.
syntax-propertize (as it stands) is probably not compatible with some of
the optimizations you use, indeed. It probably gives you other
optimization opportunities, of course. How well it would work is hard
to tell without a lot more investigation.
> I need to know whether or not syntax-propertize properly handles
> category properties.
By and large, `syntax-propertize' doesn't handle anything at all.
It does is keep track of the BEG argument for you, and it does erase the
`syntax-table' properties over BEG..END before calling
syntax-propertize-function. But that's about all it does.
> I suspect it doesn't. That involves reading the
> source code, for lack of documentation.
The source is all in a single function (called, you guessed,
syntax-propertize) which weighs in at 39 lines of Elisp code, a good
half of which has to do with calling
syntax-propertize-extend-region-functions.
> syntax-propertize needs a way of customizing its before-change function
> to avoid removing ST properties needlessly from large chunks of buffer.
Note that in 99% of the cases, there aren't any properties applied
further in the buffer anyway, so we don't actually "needlessly"
throwaway data on large chunks of buffer.
That's why so far, this optimization you're suggesting has not been
requested by anyone, even though modes such as (C)perl do have rather
complex/costly syntax-propertize-functions and are sometimes applied to
very large buffers as well. IOW, I wouldn't worry about this problem
for now. We'll cross this bridge when we get there.
Stefan
next prev parent reply other threads:[~2014-09-14 4:04 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-02 5:26 POC: customizable cc-mode keywords Daniel Colascione
2014-05-10 23:13 ` Daniel Colascione
2014-05-11 21:13 ` Alan Mackenzie
2014-05-11 21:23 ` Daniel Colascione
2014-05-16 17:52 ` Alan Mackenzie
2014-05-16 18:06 ` Daniel Colascione
2014-05-18 21:33 ` Alan Mackenzie
2014-05-18 22:28 ` Daniel Colascione
2014-05-19 2:25 ` Stefan Monnier
2014-05-25 18:08 ` Alan Mackenzie
2014-09-08 17:28 ` Stefan Monnier
2014-09-11 13:55 ` Further CC-mode changes Stefan Monnier
2014-09-12 23:59 ` Alan Mackenzie
2014-09-13 1:09 ` Ivan Andrus
2014-09-13 10:04 ` Alan Mackenzie
2014-09-13 3:04 ` Stefan Monnier
2014-09-13 15:10 ` Alan Mackenzie
2014-09-13 19:24 ` Stefan Monnier
2014-09-13 23:08 ` Syntax-propertize and CC-mode [Was: Further CC-mode changes] Alan Mackenzie
2014-09-14 4:04 ` Stefan Monnier [this message]
2014-09-16 17:30 ` Sync'ing cc-mode Stefan Monnier
2014-09-26 19:19 ` Stefan Monnier
[not found] ` <jwv4mvmjl0c.fsf-monnier+emacs@gnu.org>
[not found] ` <jwv4mvkqy4g.fsf-monnier+emacs@gnu.org>
[not found] ` <jwv4mv3mn2a.fsf-monnier+emacs@gnu.org>
[not found] ` <jwv38a644p7.fsf-monnier+emacs@gnu.org>
[not found] ` <jwvppd2wx7o.fsf-monnier+emacs@gnu.org>
[not found] ` <20141106104534.GA3385@acm.acm>
2014-11-06 14:06 ` bug#18022: " Stefan Monnier
2014-09-15 20:24 ` Further CC-mode changes Glenn Morris
2014-09-16 3:07 ` Stephen J. Turnbull
2014-09-16 13:39 ` Stefan Monnier
2014-09-16 14:22 ` David Kastrup
2014-09-16 23:40 ` Stephen J. Turnbull
2014-09-17 1:02 ` Stefan Monnier
2014-09-17 1:48 ` Stephen J. Turnbull
2014-09-17 5:22 ` David Kastrup
2014-09-17 13:00 ` Stefan Monnier
2014-09-17 18:31 ` Glenn Morris
2014-09-17 19:12 ` David Kastrup
2014-09-17 5:24 ` Eli Zaretskii
2014-09-17 6:54 ` Stephen J. Turnbull
2014-09-17 7:20 ` Eli Zaretskii
2014-09-17 7:30 ` David Kastrup
2014-09-17 13:04 ` Stefan Monnier
2014-09-17 18:25 ` Glenn Morris
2014-09-18 5:20 ` Stephen J. Turnbull
2014-09-18 9:44 ` Emilio Lopes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvy4tmhoad.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=acm@muc.de \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.