Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls

[Stefan Monnier]

>> > I don't rate restrictions on the use of Emacs primitives to be minor.
>> I think there's a fundamental misunderstanding abut Dmitry's suggestion
>> here: his proposal does not restrict the use of any primitive anywhere.
> You say there's no restriction happening, then go on to detail the
> restriction that is to be put in place.  ;-)

I have no idea what you're talking about.  Where did you see a restriction?
There are only guidelines, no restrictions.

> Typically the code does need to know about "distant" chunks.

The years of experience with mmm-mode, as well as the more recent
experience with mhtml-mode disagree with this.

> For example if point is after an embedded AWK Mode script in
> shell-script-mode, C-M-a will need access to the buffer part before
> the AWK Mode interlude.

This already works and won't be affected by the proposal.

>> (add-hook 'syntax-propertize-extend-region-functions
>> #'syntax-propertize-multiline nil t)
> All constructs in CC Mode languages are "multiline".

So what?

>> when you find (and put the syntax-table property on) the <...> pair.
> Why not just put that property on the entire buffer?  Or, if
> syntax-multiline is intended to flag up just one construct, it won't cope
> well with nested (or overlapping) constructs.

As I said, you don't have to use that.  You can write your own
syntax-propertize-extend-region-function any which way you like.

>> Of course, it's not the only possible way to do it.  It's just the way
>> I solved similar problems in perl-mode and sh-mode.
> How is that going to help when a closing template delimiter is deleted?

It will cause the re-propertization to be done from the matching
opening delimiter (at least, if you've set things up correctly, of
course: syntax-propertize itself has no idea about those delimiters).

> One problem is the vagueness in the documentation of
> syntax-propertize-extend-region-functions.  Are these functions called in
> before-change-functions or a-c-functions?  Obviously, in my case above,
> they would be needed in b-c-f, otherwise they wouldn't notice the ">"
> being killed.

The text between < and > is marked, what when BEG falls in the middle, 
syntax-propertize-extend-region-functions will know without having to
have access to the ">" (so it doesn't matter if it's already been
deleted or not).

> But they need to be called in a-c-f too, in case the
> change is adding "> >", when the code needs to search back to the earlier
> two "<"s, which now have become "dirty" when they weren't previously.

This kind of complexity disappears in syntax-propertize's approach.

> syntax-propertize splats all syntax-table properties after a change
> point, if I understand correctly.  That means they must at some point
> soon be regenerated[*].  This will be expensive in a large buffer.

This *can* be expensive, but they're only regenerated lazily, so
typically it's not a problem.  We have many years of experience in many
different major modes to say that it's likely not to be a problem.

> Several differences in performance that "hardly matter" can add up to
> something substantial.

"can", indeed.  My experience makes me confident it won't happen.


        Stefan