emacs-devel
[Top][All Lists]
Advanced

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

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


From: Stefan Monnier
Subject: Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls
Date: Sun, 03 Dec 2017 13:40:22 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

> Details do matter.  I posted a full proposal, Subject: "Syntax
> ambiguities in narrowed buffers and multiple major modes: a proposed
> solution."  here in emacs-devel on Sat, 25 Feb 2017 13:53:56 +0000.

For the reasons exposed before, contrary to Dmitry, I don't really care
about seeing a detailed proposal.  I know full well that I'm absolutely
unable to run such the paper-design in my head and predict if it'll
really work.

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

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

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

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

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).  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.  I strongly doubt that the difference
in performance behavior will ever matter, tho.


        Stefan



reply via email to

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