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

[Alan Mackenzie]

Hello, Stefan.

On Sun, Dec 03, 2017 at 13:40:22 -0500, Stefan Monnier wrote:

[ .... ]

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

> The only thing it does is to make the calling convention of
> indent-line-function a bit more precise: instead of not saying anything
> about the kind of narrowing that can be in place when that is called, it
> specifies that the caller should arrange the narrowing to expose "all"
> the code, and so the callee doesn't need to widen (which is useful since
> in an MMM context, the sub-mode usually doesn't know how far it should
> widen).

Which is why I proposed the "syntactic islands", which would allow code
to do parse-partial-sexp (or even syntax-ppss).  Typically the code does
need to know about "distant" chunks.  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.

> The indent-line-functions can still narrow/widen all it wants.
> And the callers of indent-line-function also can still widen/narrow all
> they want.  Just as is the case now, depending on how they narrow/widen
> the result may be incorrect.  And the novelty here is to provide
> a convention that, if followed, should make it more likely that the
> result is correct, without the caller and the callee being aware of each
> other, because they only care about the shared convention.

> > If those common solution are adequate, yes.  But it is also critical to
> > have the freedom to depart from things like syntax-propertize when they
> > are inadequate, or too awkward.  syntax-propertize is inadequate for CC
> > Mode:

> > E.g., in C++ Mode, with

> >     foo (a < b, c > d);

> > we have a constructor foo with one parameter d, of a templated type.  The
> > characters "<" and ">" have syntax-table text properties giving them
> > paren syntaxes and making them match each other.

> > Now, mark the characters ", c > d" and kill them with C-w.  What we are
> > left with is a function call with an integer argument a < b:

> >     foo (a < b);

> > .  Something, somewhere has to remove the syntax-table property from
> > "<", since it is no longer a template delimiter.

> > The syntax-propertize mechanism won't do this, since the place to
> > de-propertise is before BEG.

> syntax-propertize is no silver bullet, indeed, so it won't do everything
> magically for you.  But, it can handle the above situation just fine.

I don't see that.

> In your very specific above example, it will actually be handled
> magically simply by virtue of syntax-propertize-wholelines being
> included in the default value of syntax-propertize-extend-region-functions.

> Now, of course, if you tweak your example so that the < and the > are
> not on the same line any more, that magic won't work.  But that doesn't
> mean you can't make syntax-propertize handle it right.  You could for
> example solve it with:

>     (add-hook 'syntax-propertize-extend-region-functions
>               #'syntax-propertize-multiline nil t)

All constructs in CC Mode languages are "multiline".

> in your major mode function and

>     (put-text-property position-of-left-< position-of-right->
>                        'syntax-multiline t)

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

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

> If you're interested in making CC-mode work reliably with
> syntax-propertize I'd be *thrilled* to help you do that.

> By design, there should be basically nothing syntax-propertize can't handle
> (modulo bugs and within the limits of what we can do with syntax-tables
> and syntax-table properties, obviously).

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

> I have no doubt that the way CC-mode works right now will occasionally
> be more efficient than the way syntax-propertize would do it.  But I
> also have no doubt that the way syntax-propertize would do it will
> occasionally by more efficient than the way CC-mode does it right now.

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.

[*] imagine moving point forward to just before a "<" which (along with
its matching ">") needs to have paren s-t. properties to allow
paren-matching to happen.  I can't see what is putting those properties
on it, given the ">" could be an arbitrary distance forward.

> I strongly doubt that the difference in performance behavior will ever
> matter, tho.

Several differences in performance that "hardly matter" can add up to
something substantial.  I recently celebrated a 3.9% increase in
fontification performance after deleting some old duplicate code.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).